The Shared WiFi Password Problem: A Disaster Waiting to Happen

Walk into almost any Norwegian office building, healthcare facility, or school, and you will likely find a WiFi password written on a whiteboard, taped to a desk, or shared in a group chat. This is not laziness — it is the default outcome of deploying wireless infrastructure without investing in proper authentication infrastructure. The result is a single shared pre-shared key (PSK) that grants network access to every device, every user, and every visitor who has ever connected — including those who left the organisation three years ago.

The risks are not theoretical. When a single shared password is used across an entire organisation, any one of the following scenarios can cascade into a significant security incident:

• One compromised device exposes everyone. A contractor connects their malware-infected laptop. Because 802.11 WPA2-PSK encrypts traffic between devices and the access point using a derivation of the shared key, other devices on the same network are potentially exposed to man-in-the-middle attacks from that device. With the PSK, an attacker can derive the per-session encryption keys from captured handshakes.
• No per-user audit trail. Your SIEM logs show a connection from 192.168.1.45 at 03:14. Who was it? You have no idea, because every device authenticates with the same credential. Forensic investigation becomes guesswork.
• Contractor access that never gets revoked. The consultancy finished their engagement eight months ago. Their team members still have the WiFi password. Some of them have since moved to a competitor. The password was never changed because changing it means updating every device in the building manually.
• No device-level policy enforcement. A personal device and a corporate-managed laptop look identical from the network perspective. You cannot apply different access policies, segment them into different VLANs, or enforce compliance posture as a condition of network access.

These are not edge cases. They are the predictable, systematic consequences of shared credential authentication. And they have been solvable for over two decades — the technology is called 802.1X, and the delivery model that makes it practical for organisations of every size is RADIUS-as-a-Service.

802.1X Fundamentals: The Three-Party Handshake

IEEE 802.1X is a port-based network access control standard. It was ratified in 2001 and remains the foundation of enterprise wireless and wired authentication. Understanding it requires understanding three roles:

• Supplicant. The client device seeking network access — a laptop, smartphone, tablet, or IoT device. The supplicant runs an 802.1X client, which is built into every modern operating system including Windows, macOS, iOS, Android, and most Linux distributions.
• Authenticator. The network device that enforces access control — typically a wireless access point or a managed ethernet switch. The authenticator does not make authentication decisions; it acts as a relay. It holds the port in an unauthorised state until it receives approval from the authentication server.
• Authentication Server. The RADIUS (Remote Authentication Dial-In User Service) server that validates credentials and returns an access decision — accept, reject, or challenge. It also carries policy information: which VLAN to assign, which ACLs to apply, what bandwidth limits to enforce.

The protocol that carries authentication data between the supplicant and the RADIUS server (through the authenticator) is the Extensible Authentication Protocol (EAP). EAP is a framework, not a specific authentication mechanism. It supports a large number of inner methods:

• PEAP (Protected EAP). Encapsulates EAP inside a TLS tunnel. The most common inner method is MSCHAPv2, which authenticates the user with a username and password. PEAP with MSCHAPv2 is widely deployed and supported by every major platform without additional client software. However, it still relies on passwords — and passwords can be phished, cracked, or leaked.
• EAP-TLS. Uses mutual TLS authentication. The server presents a certificate to prove its identity, and the client presents a certificate to prove its identity. There is no password involved. The private key never leaves the device. This is the gold standard of 802.1X authentication and the foundation of true passwordless network access.
• EAP-TTLS. Similar to PEAP, but more flexible in the inner authentication methods it supports. Common in environments with heterogeneous client types.

The authentication flow in an 802.1X environment works as follows: The supplicant connects to the network and the authenticator begins the EAP exchange. The RADIUS server challenges the supplicant, the supplicant responds with its credentials (certificate or password), and the RADIUS server validates the response against its policy database. If accepted, the RADIUS server sends an Access-Accept message — potentially carrying VLAN assignment attributes — and the authenticator opens the port.

Certificate-Based Authentication: Why It Is Fundamentally Stronger

The shift from credential-based to certificate-based authentication is not merely an incremental improvement — it eliminates entire categories of attack.

With EAP-TLS and client certificates, the authentication proof is a cryptographic operation performed using a private key. The private key never leaves the device. There is no secret that can be stolen from a database, no credential that can be phished from a user, and no password that can be guessed through brute force. Consider what this eliminates:

• Phishing. A user cannot be tricked into entering their WiFi credentials on a fake captive portal, because there are no credentials to enter. The device authenticates silently, using the certificate stored in its secure enclave or TPM.
• Credential stuffing. Stolen username and password combinations are useless. The authentication server expects a valid certificate, not a password.
• Password spraying. There is nothing to spray against.
• Pass-the-hash. Not applicable in a certificate-based authentication flow.

Beyond what certificates prevent, they provide something credentials cannot: device identity. A certificate is issued to a specific device. Its serial number, common name, and Subject Alternative Names tie it to a known, managed endpoint. When a device authenticates with its certificate, the RADIUS server does not just know who is connecting — it knows which device is connecting. This enables policies that were previously impossible:

• Allow only company-managed devices onto the corporate network, regardless of whose credentials are used.
• Deny access to devices whose certificates have been revoked — immediately, without any password change cycle.
• Tag connections with device identity for use in downstream policy enforcement (firewall rules, DLP, SIEM correlation).

Certificate revocation is another critical advantage. When an employee leaves, their device certificate is revoked. The next time that device attempts to connect, the RADIUS server checks the Certificate Revocation List (CRL) or queries OCSP and denies the connection — even if the device physically still holds the certificate. Compare this to revoking a WiFi password, which requires changing the PSK everywhere simultaneously.

Cloud RADIUS: Eliminating the On-Premises Complexity Trap

The historical barrier to 802.1X adoption was not technical — the standard has been mature for over two decades. The barrier was operational. Running a RADIUS server on-premises is not trivial:

• You need at least two servers for high availability, ideally geographically separated.
• Those servers require OS patching, certificate lifecycle management, and monitoring.
• Configuration errors can lock users out of the network silently.
• Integration with Active Directory or Azure AD requires careful configuration of LDAP or RADIUS proxying.
• Scaling to handle authentication surges (Monday morning in a hospital, shift change in a factory) requires capacity planning.
• Disaster recovery for the RADIUS infrastructure is often an afterthought — until it becomes a crisis.

Cloud RADIUS eliminates most of this complexity. The RADIUS server runs as a managed service, operated by a provider with the operational expertise, redundancy, and capacity to deliver enterprise-grade uptime without the organisation bearing the burden of running the infrastructure. Authentication requests are forwarded from access points and switches to the cloud RADIUS endpoint via the RADIUS protocol (UDP port 1812/1813), or via a secure gateway for organisations that require traffic to stay on-premises before reaching the cloud.

ZeroSubnet operates RADIUS-as-a-Service from Norwegian infrastructure, supporting both cloud-native organisations that route authentication directly to the service and hybrid deployments that use an on-premises RADIUS proxy or NPS gateway for local redundancy. The service integrates natively with Azure Active Directory and Entra ID, and supports both certificate-based (EAP-TLS) and protected password-based (PEAP-MSCHAPv2) authentication methods, enabling organisations to migrate incrementally rather than requiring a full cutover.

MDM and PKI Integration: Automating Certificate Enrollment

The practical question with certificate-based WiFi authentication is always: how do devices get their certificates? Manually distributing certificates to every endpoint is not scalable — and it defeats the operational simplicity that RADIUS-as-a-Service is supposed to provide.

The answer is integration between the RADIUS service, the organisation's PKI (Public Key Infrastructure), and its MDM (Mobile Device Management) platform. The enrollment process typically works as follows:

• Certificate Authority. The organisation operates a private CA, either on-premises (Microsoft ADCS is the most common choice in Norwegian enterprise environments) or in the cloud (Azure Certificate Manager, or a third-party PKI-as-a-service). This CA issues the device certificates used for EAP-TLS authentication.
• SCEP (Simple Certificate Enrollment Protocol). SCEP is the protocol that enables devices to request and receive certificates automatically. The MDM platform configures a SCEP profile on each managed device, which tells the device how to contact the CA, what certificate attributes to request, and where to store the resulting certificate.
• MDM Deployment (Intune and Jamf). Microsoft Intune is the dominant MDM platform in Norwegian enterprise and public sector environments. Jamf is the standard for macOS and iOS in education. Both support deploying SCEP certificate profiles alongside WiFi configuration profiles. When a new device is enrolled in MDM, it automatically receives a SCEP certificate signed by the organisation's CA, receives the WiFi configuration profile that tells it to use EAP-TLS with that certificate, and connects to the corporate WiFi without any user interaction.

This is zero-touch onboarding for wireless. A new employee receives their laptop, powers it on, and is prompted to sign in with their corporate identity. MDM enrollment happens automatically through Autopilot (Windows) or ADE (Apple). Within minutes of first boot, the device has its certificate and is connected to the corporate WiFi. The user never sees a WiFi password prompt because there is no WiFi password.

The same flow applies to iOS and Android devices managed through Intune, with certificates delivered via SCEP and WiFi profiles pushed alongside device enrollment. Android Enterprise and Apple Business Manager both support this end-to-end automation.

Per-Device Access Control: Dynamic VLANs and Policy Enforcement

Once 802.1X is in place, the RADIUS server becomes a policy enforcement point — not just an authentication oracle. The RADIUS Access-Accept message can carry RADIUS attributes that tell the network device how to treat the authenticated session:

• Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID. These attributes instruct the switch or access point to place the authenticated device into a specific VLAN. A managed corporate laptop might be assigned to VLAN 10 (corporate), while a personal device using user credentials might be assigned to VLAN 50 (restricted), and a guest might be assigned to VLAN 99 (internet-only).
• Filter-ID or Cisco-AVPair. Used to apply ACLs (Access Control Lists) to the authenticated session, enabling per-device or per-user traffic policy at the network level.
• Session-Timeout and Termination-Action. Control how long a session remains authenticated before the device must re-authenticate, and what happens at timeout — enabling time-limited access for contractors or guests.

Dynamic VLAN assignment transforms how network segmentation works. Instead of relying on physical port assignments or manual VLAN configuration on each switch port, the RADIUS server dynamically places each authenticated device into the correct network segment based on its identity, certificate attributes, and group membership. A nurse's workstation automatically lands in the clinical systems VLAN. A visitor's phone automatically lands in the guest VLAN. No manual configuration required.

More advanced deployments integrate device health signals into the access decision. Microsoft's Network Policy Server (NPS) extension for Intune, for example, can check device compliance status — is the device encrypted? Are patches up to date? Is the EDR agent running? — before granting full network access. Non-compliant devices are redirected to a remediation VLAN where they can reach update servers but nothing else. This is network-layer enforcement of endpoint health policy.

Guest Network Segmentation Without a Shared Password

Guest network access is often the last holdout for shared passwords even in otherwise well-secured environments. The assumption is that guests cannot be expected to have certificates, and a PSK is the only practical option.

This is not true. Several approaches eliminate the shared password for guest networks:

• Sponsored guest access via captive portal. Guests connect to an open SSID and are redirected to a captive portal. A sponsor (an employee) approves the guest access request, and the guest receives a time-limited credential. The connection is still authenticated, and there is an audit record associating the guest with their sponsor.
• WPA3-SAE (Simultaneous Authentication of Equals). Even when a guest network uses a shared passphrase, WPA3-SAE provides forward secrecy and resistance to offline dictionary attacks. Each session uses unique encryption keys regardless of the shared passphrase.
• Separate SSID with internet-only routing. A dedicated guest SSID that never touches the corporate network, firewall-enforced at the network layer. The segmentation is not dependent on the WiFi credential but on VLAN and routing policy.

The goal is not to force certificate-based authentication on every guest device — that is impractical. The goal is to ensure that guest traffic is isolated at the network layer regardless of authentication method, and that corporate resources are accessible only to authenticated, managed devices.

Azure AD and Entra ID Integration: User-Based Policies Alongside Device Certs

In most enterprise environments, device identity alone is insufficient for comprehensive access control. You also need user identity — to apply policies based on group membership, to capture per-user audit logs, and to handle scenarios like shared devices where a single device is used by multiple users with different access levels.

Azure Active Directory (now Entra ID) integration with RADIUS-as-a-Service enables user-based policies to coexist with device certificate authentication. Several integration patterns are common:

• RADIUS with Azure AD via NPS Extension. Microsoft provides an NPS extension that proxies RADIUS authentication to Azure AD. This enables MFA enforcement for network access — a user authenticating via PEAP-MSCHAPv2 is challenged with Azure MFA before the RADIUS Access-Accept is returned. This is a significant improvement over password-only PEAP, though it still relies on passwords as the primary factor.
• RADIUS with Entra ID Certificate-Based Authentication (CBA). Entra ID now supports certificate-based authentication, meaning device certificates issued by the organisation's CA can be validated against Entra ID user objects. This allows the RADIUS server to validate both the device certificate (proving device identity and MDM enrollment) and tie the authentication to a specific Entra ID user account (enabling group-based policy).
• Hybrid EAP-TLS for device with user lookup via LDAP. The RADIUS server validates the device certificate, then uses the certificate Common Name or SAN to look up the associated user in Azure AD. Group membership returned by this lookup informs VLAN assignment and policy decisions.

This integration means that when a device connects, the RADIUS server knows: which device it is (certificate subject), who the primary user of that device is (Entra ID lookup), what groups that user belongs to (Entra ID group membership), and whether the device is compliant (MDM status). The access decision is the product of all four factors — not just whether this device has a certificate.

GDPR and Audit: Per-User, Per-Device Connection Logs

Norwegian organisations operating under GDPR have specific obligations around data processing and security incident response. Network access logs are a foundational element of both.

With shared PSK authentication, the most you can log is the MAC address of connecting devices. MAC address logging has two problems: MAC randomisation (enabled by default on iOS, Android, and Windows since 2021) means the same device presents a different MAC address each time, and a MAC address tells you nothing about who is using the device.

With 802.1X authentication, the RADIUS accounting stream (RADIUS Accounting, UDP port 1813) generates a structured log for every authentication event: timestamp, NAS-Identifier (which access point or switch), NAS-Port (which physical or logical port), User-Name (the certificate CN or username), Called-Station-Id (the AP BSSID and SSID), session ID, bytes transferred, and session duration.

This gives you a complete, per-device, per-user audit trail of network access. You know exactly which device connected, which user it is associated with, which access point they used, when the session started and ended, and how much data was transferred. This is the level of logging that GDPR incident response requires — being able to answer precisely who had access to the network during a specific window with a definitive answer, not a probabilistic guess.

ZeroSubnet's RADIUS-as-a-Service retains accounting logs with configurable retention periods, exportable to SIEM platforms via syslog or API integration. Logs are stored on Norwegian infrastructure, supporting data residency requirements for public sector and healthcare organisations subject to Norwegian data localisation obligations.

Norwegian Context: Sectors With Strict Access Control Requirements

Norway has several regulated sectors where the consequences of inadequate network access control are particularly acute:

• Healthcare (Helse-sektoren). Hospitals, GP practices, and healthcare trusts handle patient data (helseopplysninger) subject to strict access control requirements under the Health Records Act (helseregisterloven) and GDPR. Network access logs are required for audit purposes, and per-user authentication is expected. NHN (Norsk helsenett) connectivity requirements mandate structured access control for connected organisations.
• Education (Utdanningssektoren). Universities and upper secondary schools operate bring-your-own-device (BYOD) environments with thousands of student devices. Separating student devices from staff infrastructure, applying content filtering per device category, and maintaining accurate access logs for GDPR compliance all require 802.1X.
• Municipal and Government. Norwegian municipalities operate under NSM (Nasjonal sikkerhetsmyndighet) guidance on ICT security. NSM's basic principles (Grunnprinsipper for IKT-sikkerhet) explicitly recommend network segmentation and authenticated access control as foundational controls. Many municipalities are also subject to the NIS2 directive requirements being transposed into Norwegian law.
• Financial Services. Norwegian banks and financial institutions operate under DORA (Digital Operational Resilience Act) requirements and Finanstilsynet guidance. Network access control is an expected control in any financial sector ICT risk framework.

Closing: ZeroSubnet RADIUS-as-a-Service

Passwordless network access via 802.1X certificate authentication is no longer an enterprise-only capability. ZeroSubnet delivers RADIUS-as-a-Service from Norwegian infrastructure, removing the complexity of operating RADIUS servers while providing the full capability of enterprise-grade network access control.

Our service supports both cloud-native and hybrid deployment models. For organisations with Azure infrastructure, we integrate directly with Entra ID for user-based policy and support Intune SCEP certificate profiles for zero-touch device onboarding. For organisations with on-premises requirements, we support NPS proxy deployments and on-premises gateway configurations that provide local authentication continuity even during cloud connectivity interruptions.

Eliminating shared WiFi passwords is not a complex project. It is a configuration change — if you have the right infrastructure behind it. ZeroSubnet provides that infrastructure, configured and operated by Norwegian security professionals who understand the regulatory landscape, the common edge cases, and the operational requirements of running authentication infrastructure that your users depend on every working day.

Contact us to discuss your environment. Whether you are a 50-person company still using a whiteboard WiFi password or a 2,000-person enterprise with a mix of legacy switches, modern APs, and three different MDM platforms, we have deployed 802.1X in environments like yours — and we know where the complexity hides.