Best WiFi authentication system 2026

Table of Contents

WiFi Authentication System: How Wireless Access Control Actually Works

WiFi authentication system design is the layer most deployments get wrong before they get anything else wrong, because it is the decision that constrains everything built afterwards.

Choose a shared password and you have permanently forfeited the ability to identify users, apply per-user policy, revoke access for one person, or produce a meaningful log of who did what. Choose a captive portal alone and you have a login page sitting on top of an unencrypted network, which is a billing mechanism rather than a security control.

Choose enterprise authentication without understanding certificate handling and you have a deployment that works perfectly on the test laptop and fails on half the devices that turn up. The confusion is understandable, because the terminology overlaps in unhelpful ways — authentication, authorisation, encryption and accounting are distinct functions that people routinely conflate, and vendors describe products in ways that blur them further.

This guide works through the layer properly: what a WiFi authentication system actually does, how RADIUS and 802.1X fit together, which EAP method to use and why, where captive portals belong and where they do not, how certificates work in practice, and how to choose an approach for a real deployment with mixed devices and constrained budgets.

It is written for whoever has to build or specify the thing rather than for whoever signs the purchase order, and the design decisions behind a WiFi authentication system matter more than the hardware brand, because a well-designed WiFi authentication system survives an equipment change while a badly designed one has to be rebuilt.

Authentication, Authorisation, Encryption and Accounting
What Goes Wrong Without Proper Authentication
The Open Network
Pre-Shared Key and Its Limits
Per-User Pre-Shared Keys
Enterprise Authentication: The Architecture
How 802.1X Works
The Role of RADIUS
EAP Methods Compared
Certificates: What They Do and Why
Server Certificate Validation on Clients
Client Certificates and EAP-TLS
Captive Portals: Purpose and Limits
Combining Portals With Encryption
MAC Address Authentication
MAC Randomisation and What It Broke
WPA3 and Enhanced Open
Identity Sources and Directory Integration
Authorisation: Applying Policy After Login
Dynamic VLAN Assignment
Change of Authorisation and Live Sessions
RADIUS Accounting and Session Records
Device Onboarding at Scale
Guest Access Patterns
Roaming Between Access Points
Redundancy and Failure Behaviour
Common Attacks and Defences
Logging, Privacy and Retention
Choosing an Approach by Deployment Type
Implementation Order and Testing
Frequently Asked Questions

Authentication, Authorisation, Encryption and Accounting {#four-functions}

Four distinct functions are routinely conflated, and separating them clarifies most design confusion.

Authentication establishes who a user is. Authorisation determines what they are permitted to do once identified. Encryption protects traffic in transit. Accounting records what happened.

A captive portal typically provides authentication and accounting while providing no encryption at all, which is why a portal on an open network leaves traffic exposed even though users logged in.

Enterprise wireless authentication provides all four, which is why a properly designed WiFi authentication system built on it is qualitatively different from a portal bolted onto an open network, and understanding which functions your chosen approach actually delivers is the first design step in any WiFi authentication system.

What Goes Wrong Without Proper Authentication {#what-goes-wrong}

The failures are predictable and worth stating concretely, because they justify the additional complexity.

Without individual identity you cannot revoke one person’s access. A shared password requires changing the password for everyone, which means it never gets changed.

You cannot apply differentiated policy. A guest and a staff member on the same credential receive the same treatment, and a WiFi authentication system without per-user identity cannot deliver role-based access at all.

You cannot investigate an incident. Logs showing that something originated from your network with no attribution to a person are of limited use, and a WiFi authentication system that produces attributable records is what makes an investigation possible.

You also cannot bill reliably, which matters commercially wherever access is sold, since a WiFi authentication system without individual identity cannot enforce entitlement.

The Open Network {#open-network}

An open network requires no credential and provides no encryption, and it remains common despite being indefensible in most contexts.

Traffic is transmitted in the clear over the air, readable by anyone within range with commonly available tools.

Users on such networks are protected only by transport encryption within their applications, which covers most modern web traffic but not everything, and assuming it covers everything is a mistake.

Open networks also have no access control, so anyone in range is a user, which is a capacity problem as much as a security one and the reason even a free service should sit behind a WiFi authentication system of some kind.

Where an open network is genuinely necessary, the modern alternative described later provides encryption without a credential, which is strictly better and worth adopting in any new WiFi authentication system design.

Pre-Shared Key and Its Limits {#psk-limits}

A pre-shared key is the familiar network password, shared by everyone who connects.

It provides encryption, which is a genuine improvement over an open network, and it is simple to deploy.

Its limits are structural rather than incidental. Everyone shares one credential, so there is no individual identity, no per-user policy and no ability to revoke one user, and any WiFi authentication system built on a shared key inherits all of those constraints permanently.

The key also leaks inevitably. Written on a whiteboard, shared in a group chat, remembered by a departed employee, it circulates beyond the intended population, and there is no way to know it has.

Pre-shared keys remain appropriate for small deployments where everyone is trusted and the population is stable, which is a genuine category, but a WiFi authentication system for anything larger or with turnover should not rest on one.

Per-User Pre-Shared Keys {#per-user-psk}

A middle option issues a different key to each user or device on the same network name.

This restores individual identity and revocation without the client-side complexity of full enterprise authentication, which is its main attraction.

Devices that cannot support enterprise authentication — many devices with limited interfaces — can still receive an individual credential, which makes this approach useful for populations with mixed device capability, and a WiFi authentication system using it can apply per-user policy that a shared key never could.

Support varies by vendor, since this is an extension rather than a standard, so confirming that your equipment implements it before designing a WiFi authentication system around it is necessary.

It does not provide the full security properties of enterprise authentication, particularly around credential protection during connection, so it is a pragmatic middle position rather than an equivalent.

Enterprise Authentication: The Architecture {#enterprise-architecture}

Enterprise wireless authentication involves three parties, and understanding the roles clarifies everything else.

The supplicant is the client device requesting access. The authenticator is the access point or controller enforcing the decision. The authentication server holds the identity information and makes the decision.

The access point does not verify credentials itself. It passes the exchange between the client and the authentication server, which is why the access point never holds user passwords in a properly designed WiFi authentication system.

This separation is what allows a single identity source to serve an entire estate of access points, and it is why the authentication server rather than the wireless hardware is the architectural centre of a WiFi authentication system.

Encryption keys are derived per session from the authentication exchange, so each user’s traffic is protected with distinct keys rather than a shared one, which is the fundamental security advantage over a pre-shared key.

How 802.1X Works {#how-8021x-works}

The standard defines port-based network access control, and applied to wireless it governs the exchange before a device is granted network access.

The sequence is: the client associates, the access point blocks all traffic except the authentication exchange, that exchange runs between client and authentication server, and on success the access point permits traffic and applies any returned policy.

Nothing reaches the network until authentication succeeds, which is the property that distinguishes it from a captive portal where the device is on the network first and authenticates afterwards.

The exchange itself is carried by an extensible framework, which is what allows different authentication methods to be used within the same architecture, and choosing among those methods is the main design decision within a WiFi authentication system.

Client configuration is the practical complexity. Devices need to know the method, the server to trust and the credentials to present, and how you deliver that configuration is the largest operational question in any WiFi authentication system rollout.

The Role of RADIUS {#radius-role}

RADIUS is the protocol carrying authentication requests from the access point to the authentication server and the decision back.

It also carries authorisation attributes — the policy to apply to a successful session — and accounting records describing the session.

Several server implementations exist, including well-established open-source options and commercial products, and the choice depends on scale, integration requirements and available expertise rather than on protocol differences, since a WiFi authentication system works the same way regardless of which server speaks it.

Shared secrets between the access point and the server protect that exchange, and they should be strong and distinct per device rather than a single value reused across an estate, which is a common weakness in a hastily built WiFi authentication system.

The server is a critical dependency. When it is unreachable, nobody authenticates, which is why redundancy in a WiFi authentication system is a design requirement rather than a refinement.

EAP Methods Compared {#eap-methods}

Several methods exist within the framework, and the choice determines both security properties and deployment complexity.

The tunnelled password-based methods establish an encrypted tunnel using a server certificate, then carry the user’s credentials inside it. These are the most widely deployed because they use familiar username and password credentials while protecting them in transit.

Certificate-based mutual authentication is the strongest option, with both the server and the client presenting certificates and no password crossing the network at all, which removes an entire category of attack from a WiFi authentication system.

Its cost is certificate distribution and lifecycle management, which is substantial at scale and is why many deployments choose a tunnelled password method instead.

Older methods without proper protection should not be used in new deployments, and a WiFi authentication system design should specify the method explicitly rather than accepting whatever a device negotiates by default.

Certificates: What They Do and Why {#certificates}

Certificates are the mechanism by which a client can verify it is talking to the correct authentication server rather than to an impostor.

Without that verification the client will present credentials to whatever server claims the right identity, which is precisely the attack that certificate validation prevents.

The server certificate should come from a source the clients already trust, or from an internal authority whose root the clients have been given, and either path needs deciding early in a WiFi authentication system design because it affects how devices are configured.

Certificates expire, and an expired server certificate breaks authentication for everyone simultaneously, which is among the most common causes of a sudden total failure in an otherwise stable WiFi authentication system.

Track expiry dates deliberately. A calendar reminder well before expiry, with a documented renewal procedure, prevents an outage that is entirely predictable, and any WiFi authentication system runbook should include it.

Server Certificate Validation on Clients {#server-cert-validation}

This is the detail that separates a secure deployment from one that merely appears secure.

If clients are configured to accept any server certificate, or if users are prompted and click through, the protection the certificate provides is entirely lost.

Correct configuration specifies which certificate authority to trust and which server name to expect, and only then does the client refuse to authenticate against an impostor, which is what makes a WiFi authentication system resistant to credential theft over the air.

Manual configuration by end users reliably produces incorrect settings, since the options are obscure and the prompts are easy to dismiss, which is the central argument for automated onboarding in any WiFi authentication system serving non-technical users.

Test the failure case during commissioning. Confirm that a client configured by your onboarding process actually refuses an unexpected certificate, because a WiFi authentication system that silently accepts anything is providing an illusion.

Client Certificates and EAP-TLS {#client-certificates}

Certificate-based client authentication removes passwords from the equation entirely.

Each device holds its own certificate, and authentication is a mutual exchange with no shared secret to steal, phish or guess.

The security properties are excellent and the operational burden is real. Issuing, distributing, renewing and revoking certificates across a device population is an ongoing programme rather than a one-time setup, and a WiFi authentication system built this way needs a certificate infrastructure behind it.

Where devices are institutionally managed through a device management platform, the burden falls dramatically since certificates can be pushed automatically, which makes this approach natural for managed estates and awkward for bring-your-own populations.

Revocation is the operational advantage. A lost device’s certificate can be revoked immediately without affecting anyone else, which is far cleaner than any password-based WiFi authentication system alternative.

Captive Portals: Purpose and Limits {#captive-portals}

A captive portal intercepts traffic and redirects it to a login or payment page before permitting general access.

Its strengths are familiarity, zero client configuration, and suitability for transient users who will never return.

Its fundamental limit is that the device is already on the network before authentication happens, and if that network is open, traffic is unencrypted regardless of whether the user logged in, so a WiFi authentication system relying solely on a portal provides authentication and accounting but no confidentiality.

Portals are also fragile across devices. Operating systems detect them differently, some browsers handle the redirect poorly, and captive portal detection behaviour changes between versions, which means a WiFi authentication system using a portal needs testing across the actual device population rather than on one laptop.

They remain the right choice for genuinely public transient access — a hotel lobby, a market, a café — where per-device configuration is impossible, and a WiFi authentication system serving that population correctly uses a portal while understanding what it does not provide.

Combining Portals With Encryption {#portal-plus-encryption}

The weakness of a portal on an open network is addressable, and modern deployments should address it.

One approach runs the portal on a network protected by the newer opportunistic encryption mechanism, which encrypts traffic without requiring a credential.

Another issues an individual key at the point of purchase or registration, moving the user onto an encrypted network after their portal interaction, which gives a WiFi authentication system both the accessibility of a portal and the confidentiality of a keyed network.

A third offers two networks — an open portal network for transient users and an enterprise network for regulars — and encourages migration, which suits venues with both populations and is a reasonable structure for a WiFi authentication system in a hotel or campus.

Whichever you choose, be accurate about what you provide. Telling users a portal-authenticated open network is secure is not true, and a WiFi authentication system should be described honestly in whatever terms are published to users.

MAC Address Authentication {#mac-authentication}

Authenticating by hardware address permits devices from a known list without any user interaction.

It is genuinely useful for devices that cannot authenticate any other way — printers, sensors, some equipment with no user interface — and it fails as a security control because addresses are trivially spoofed.

Treat it as a convenience mechanism rather than a security one. A WiFi authentication system using address-based authentication should place those devices on a restricted network segment with limited access rather than trusting them.

Combining it with other signals helps. Restricting an address to a specific access point or time window narrows the exposure, which is a reasonable hardening measure within a WiFi authentication system where address-based access is unavoidable.

Maintaining the list is an ongoing burden that grows with the device population, and a WiFi authentication system with a large address list becomes difficult to audit, so keeping it small and reviewed is worth the discipline.

MAC Randomisation and What It Broke {#mac-randomisation}

Modern mobile operating systems present randomised hardware addresses to networks by default, and this broke a great deal of established practice.

Address-based device recognition, address-based access lists, and device counting all became unreliable, and deployments that depended on them stopped working correctly.

The change is a privacy improvement and it is not going away, so a WiFi authentication system design should assume randomised addresses rather than treating them as an exception.

The practical consequence is that device identity must come from authentication rather than from the address. A user authenticating with credentials or a certificate is identifiable regardless of what address their device presents, which is another argument for a properly authenticated WiFi authentication system over an address-based one.

Where address-based recognition is still needed, users can generally disable randomisation for a specific network, but relying on end users to do that at scale is unrealistic, so a WiFi authentication system should not depend on it.

WPA3 and Enhanced Open {#wpa3}

The current generation of wireless security standards addresses several long-standing weaknesses.

For personal networks, the newer key exchange resists the offline password-guessing attacks that affected its predecessor, which is a meaningful improvement for any WiFi authentication system using a shared key.

For enterprise networks, it strengthens cryptographic requirements and adds a stricter mode for environments needing it.

For open networks, opportunistic encryption provides confidentiality without a credential, which resolves the fundamental weakness of open public networks and should be adopted in any new WiFi authentication system serving transient users.

Client support has become broad but is not universal, particularly among older devices, so transitional configurations supporting both generations are common while a WiFi authentication system serves a mixed device population.

Identity Sources and Directory Integration {#identity-sources}

The authentication server must check credentials against something, and that identity source is usually an existing system.

Directory services holding organisational accounts are the common source, letting users authenticate with the credentials they already have.

Database-backed user stores suit service providers whose subscribers exist in a billing system rather than a directory, and a WiFi authentication system for an ISP typically authenticates against subscriber records with entitlement attached.

Federated sources allow authentication against an external identity provider, which is what makes cross-institution roaming possible.

Whichever source you use, the synchronisation question matters. A user disabled in the directory should lose network access promptly, and a WiFi authentication system checking live rather than against a cached copy achieves that automatically.

Authorisation: Applying Policy After Login {#authorisation}

Authentication establishes identity; authorisation determines what that identity may do.

The authentication server returns attributes alongside its accept decision, and the access point applies them to the session.

Common attributes include a network segment assignment, bandwidth limits, session duration and access control policy, which is how a single WiFi authentication system delivers different treatment to staff, students, guests and devices on one wireless network.

Group membership in the identity source is the usual basis. A user in a staff group receives staff policy without any per-user configuration, and a WiFi authentication system designed around groups scales where per-user rules do not.

Attribute support varies by equipment vendor, so confirming that your access points honour the attributes you intend to use is a necessary step before designing policy into a WiFi authentication system.

Dynamic VLAN Assignment {#dynamic-vlan}

Placing users on different network segments based on identity is among the most useful authorisation capabilities.

One wireless network name can serve staff, students and contractors, with each landing on a separate segment with its own routing and firewall policy.

The benefit is that segmentation follows the person rather than the network they connected to, which is both simpler for users and more robust than expecting them to choose the correct network, and a WiFi authentication system using dynamic assignment eliminates a whole category of user error.

The infrastructure must support it end to end. Segments must exist on the switching between the access points and the core, and a WiFi authentication system design that assumes dynamic assignment without confirming the wired network can carry those segments will fail during commissioning.

Fallback behaviour needs defining. Where the server returns no segment attribute, the session should land somewhere restricted rather than somewhere privileged, and a WiFi authentication system should fail closed rather than open.

Change of Authorisation and Live Sessions {#coa}

Without a mechanism to alter an active session, policy changes only apply when a user reconnects.

Change of authorisation lets the server instruct the access point to modify or terminate an existing session immediately.

The applications are practical. Disconnecting a user whose subscription expired, quarantining a device detected generating malicious traffic, or upgrading a user who just purchased more bandwidth all require it, and a WiFi authentication system without it applies changes only at the next association.

For commercial deployments this is close to essential. A subscriber who pays for reactivation expects immediate service, and a WiFi authentication system that makes them wait for a session timeout produces a support call every time.

Support varies by equipment, so confirm it explicitly rather than assuming, since discovering its absence after building a WiFi authentication system around instant activation is an expensive surprise.

RADIUS Accounting and Session Records {#accounting}

Accounting records describe sessions — start, stop, duration, data transferred and the identity involved.

These records serve billing, capacity analysis, troubleshooting and incident investigation, which makes them valuable well beyond their original purpose.

Interim updates during long sessions matter for accuracy. Without them, a session that ends abnormally may never produce a stop record, and a WiFi authentication system relying only on stop records will show sessions that appear to run indefinitely.

Storage and retention need planning. Accounting records accumulate quickly at scale, and a WiFi authentication system generating them for thousands of users produces substantial volume, so both database sizing and a retention policy are design considerations.

Data quality determines usefulness. Accounting records that cannot be tied to a person because the identity field is generic serve no investigative purpose, which is another consequence of building a WiFi authentication system on shared credentials.

Device Onboarding at Scale {#onboarding}

Getting devices correctly configured is the largest practical obstacle to enterprise authentication, and it deserves as much planning as the server design.

Manual configuration works for a handful of devices and fails at any scale, because the settings are obscure and users get them wrong in ways that silently disable security.

Managed devices are straightforward. A device management platform pushes the configuration and any certificate, and a WiFi authentication system serving a managed estate has effectively solved onboarding.

Bring-your-own populations need a provisioning tool. Onboarding utilities that configure the device correctly after the user authenticates once are the standard answer, and a WiFi authentication system serving students or staff personal devices should budget for one.

Test across the actual device range before rollout. Configuration profiles behave differently across operating systems and versions, and a WiFi authentication system that works on current devices may fail on the older handsets a significant share of users carry.

Guest Access Patterns {#guest-access}

Guests need access without the configuration burden that enterprise authentication imposes.

The common pattern is a separate network with a portal, isolated from internal systems and given lower priority.

Sponsored access adds accountability. A guest registers and a staff member approves, tying the guest to a responsible internal person, which gives a WiFi authentication system attribution that a purely anonymous portal lacks.

Time-limited credentials are the norm, expiring automatically rather than requiring cleanup, and a WiFi authentication system should default guest access to a short duration with a simple extension path.

Isolation is the security requirement rather than the authentication mechanism. Guest traffic should be unable to reach internal networks regardless of how the guest authenticated, and that separation belongs in the network design rather than in the WiFi authentication system policy alone.

Roaming Between Access Points {#roaming}

Users move, and how authentication behaves during movement determines whether that movement is noticeable.

Full reauthentication at every access point produces a pause that interrupts calls and streams, which is why fast transition mechanisms exist.

These allow a client to move between access points within the same deployment without repeating the full exchange, and a WiFi authentication system supporting them delivers seamless movement for users walking through a building.

Client support varies, and some older devices handle transitions poorly regardless of infrastructure support, so testing with representative devices is worthwhile before assuming a WiFi authentication system delivers seamless roaming.

Cross-organisation roaming through federation is a different mechanism entirely, letting a visitor authenticate against their home institution, and participating requires coordination with the relevant federation body rather than only a local WiFi authentication system configuration.

Redundancy and Failure Behaviour {#redundancy}

The authentication server is a single point of failure for network access, and design must account for that.

Multiple servers configured on the access points, with automatic failover, is the basic requirement, and access points should be configured with a secondary server rather than one.

Server placement matters. Servers reachable only across a link that also carries user traffic will be unreachable exactly when a network problem occurs, so a WiFi authentication system should place authentication infrastructure where it survives partial failure.

Define the failure behaviour deliberately. Whether an access point that cannot reach any server denies all access or permits limited access is a policy decision with real consequences, and a WiFi authentication system should have that behaviour configured intentionally rather than left at a default nobody examined.

Identity source failure is a separate case. Where the server depends on a directory that becomes unreachable, authentication fails even though the server itself is running, and a WiFi authentication system design should consider caching or a secondary identity path.

Test failover in commissioning rather than discovering it during an incident, because a configured secondary server that was never verified frequently turns out not to work.

Common Attacks and Defences {#attacks-defences}

Several attacks target wireless authentication specifically, and understanding them informs configuration.

The evil twin presents a network with the same name and captures credentials from clients that connect. Server certificate validation is the defence, which is why the earlier point about client configuration matters so much.

Offline password attacks against captured handshakes affect shared-key networks, and the newer key exchange resists them, which is a strong reason to move a WiFi authentication system off the older personal mode.

Deauthentication attacks force clients to disconnect, and management frame protection mitigates them, which should be enabled where equipment supports it.

Credential sharing is the everyday problem rather than a sophisticated attack, and detecting one identity in use from many devices simultaneously is a straightforward check that a WiFi authentication system can flag.

Rogue access points on your premises are a physical and monitoring problem, and a WiFi authentication system deployment should include some capability to detect them.

Logging, Privacy and Retention {#logging-privacy}

Authentication and accounting produce records tying identified individuals to times, locations and volumes of activity.

That is personal data, and the Data Protection Act applies to how it is collected, stored, accessed and retained.

Purpose limitation governs. Data collected to operate and secure the network should be used for that, and repurposing it to monitor individuals’ movements or behaviour is a different purpose requiring its own basis, which is a decision for the organisation rather than for whoever configures the WiFi authentication system.

Retention should be defined and limited rather than indefinite, and a WiFi authentication system with configurable retention allows a policy that can actually be defended.

Internal access control matters. Not everyone administering the network needs to query individual session histories, and role separation within the WiFi authentication system management interface makes that restriction real. Specific obligations are a matter for professional advice rather than for a vendor to determine.

Choosing an Approach by Deployment Type {#choosing-approach}

The right approach follows the deployment rather than a general preference.

Managed organisational estates with a directory and device management should use enterprise authentication with a tunnelled password method, or certificates where the management platform makes distribution straightforward.

Institutions with large bring-your-own populations need enterprise authentication plus a provisioning tool, since a WiFi authentication system at that scale cannot rely on manual configuration.

Public venues serving transient users need a portal, ideally on an encrypted open network, accepting that the WiFi authentication system provides authentication and accounting rather than per-user confidentiality on a keyed network.

Service providers selling access need a subscriber-backed authentication server with authorisation attributes and live session modification, which is a different emphasis again within the same WiFi authentication system architecture.

Small trusted deployments can reasonably use a shared key, and a WiFi authentication system design should not add complexity a five-person office will never benefit from.

Implementation Order and Testing {#implementation}

Build and verify in stages, because a partially working authentication deployment is difficult to diagnose after the fact.

Stand up the authentication server and confirm it responds correctly to test requests before touching any access point.

Connect the identity source next and verify that a known account authenticates and an unknown one does not, which establishes the core of the WiFi authentication system before any wireless complexity is added.

Bring up one access point and one test client, then verify not only that authentication succeeds but that certificate validation is genuinely enforced, because a WiFi authentication system that succeeds against any certificate has failed silently.

Add authorisation attributes third, confirming that segment assignment and limits apply as intended. Add accounting fourth and verify records are complete. Only then roll out to the wider estate, testing across the actual device population rather than one laptop, and document the configuration so that whoever maintains the WiFi authentication system after you can understand it.

Frequently Asked Questions {#faqs}

What is the difference between a captive portal and enterprise authentication?
A portal authenticates a device that is already on the network, typically an open one, so it provides identity and accounting but no per-user encryption. Enterprise authentication happens before network access is granted and derives per-session encryption keys, providing all four functions.

Is a shared network password ever acceptable?
For small, stable, trusted populations, yes. It provides encryption and is simple. It cannot provide individual identity, per-user policy or selective revocation, and it leaks inevitably, so it does not suit larger deployments or any population with turnover.

Which EAP method should I use?
A tunnelled password method for most deployments, since it uses familiar credentials while protecting them. Certificate-based mutual authentication is stronger and appropriate where a device management platform can distribute certificates. Avoid older unprotected methods entirely.

Why does certificate validation matter so much?
Because without it, a client will present credentials to any server claiming the right identity, which is exactly how credential theft over the air works. If clients accept any certificate or users click through prompts, the protection is entirely lost.

Why did MAC address filtering stop working?
Modern mobile operating systems randomise hardware addresses by default as a privacy measure. Address-based recognition, filtering and device counting all became unreliable, so device identity should come from authentication rather than from the address.

Do I need Change of Authorisation?
For commercial deployments, effectively yes. Without it, a subscriber who pays for reactivation waits for their session to expire before service resumes, and a compromised device cannot be quarantined until it reconnects.

What happens if the authentication server fails?
Nobody authenticates. Configure multiple servers with automatic failover, place them where they survive partial network failure, decide deliberately whether access points fail closed or open, and test the failover during commissioning rather than during an incident.

How do I get hundreds of devices configured correctly?
Managed devices through a device management platform. Unmanaged personal devices through a provisioning tool that configures the device after a one-time authentication. Manual configuration at scale reliably produces incorrect settings that silently disable the protections the WiFi authentication system was built to provide.

WiFi Authentication System | RADIUS, 802.1X, Captive Portals & Design