The compliance case for passwordless WiFi: HIPAA, PCI, ISO 27001

Passwordless WiFi, meaning 802.1X with certificate-based EAP-TLS, is not mandated by HIPAA, PCI DSS 4.0 or ISO 27001:2022. All three expect unique identification, strong encryption, prompt revocation and audit logs. A shared password struggles on every count. Per-device certificates meet each expectation by design and produce the logs an auditor samples.

What does passwordless WiFi compliance actually mean?

Passwordless WiFi replaces a shared network password with a credential unique to each device or person. In enterprise networks this usually means IEEE 802.1X, the standard for port-based network access control. 802.1X hands the decision to a RADIUS server. RADIUS is the protocol access points use to ask an authentication server whether a device may join.

The strongest method is EAP-TLS (Extensible Authentication Protocol with Transport Layer Security). Both the device and the server present digital certificates. There is no password to phish, share or write on a breakroom whiteboard. Each session derives its own encryption keys under WPA2-Enterprise or WPA3-Enterprise.

Two related methods need flagging:

• PEAP (Protected EAP) with an account name and password is 802.1X, but it is not passwordless. It inherits every weakness of the password behind it.
• iPSK (identity pre-shared key) gives each device its own key on a single network name. It is a practical bridge for equipment that cannot hold a certificate.

"Passwordless WiFi compliance" is shorthand for one question. Does the way your staff and devices join the network satisfy the access, encryption and logging controls you are audited against? None of the three frameworks in this guide names EAP-TLS. All three describe outcomes that a shared password makes hard to evidence.

Why does a shared WiFi password fail an audit?

A pre-shared key (PSK) is one secret known by everyone on the network. That single fact creates four audit problems.

• No attribution. Every device authenticates with the same secret. Logs show a MAC address, not a person, and MAC addresses can be spoofed.
• Revocation means rotation. Removing one leaver means changing the key on every device. PCI DSS Requirement 2.3.2 makes that rotation mandatory on networks connected to card data.
• Wide blast radius. One leaked key exposes the whole network, and often every site that shares it.
• Thin evidence. You cannot show an auditor who knew the key, when they learned it, or that former staff no longer hold it.

Certificate-based access reverses each point. Every connection carries a unique identity. Revoking one certificate or disabling one account removes one device or one person. Nobody knows a key, so nobody leaves with one.

How does certificate-based WiFi meet PCI DSS 4.0?

PCI DSS v4.0 became the only active version when v3.2.1 retired on March 31, 2024. Its future-dated requirements became mandatory on March 31, 2025. The v4.0.1 limited revision, published in June 2024, uses the same requirement numbers referenced below.

Is passwordless WiFi PCI compliant?

Not on its own. PCI compliance belongs to the assessed environment, not to a product. Passwordless WiFi does satisfy or simplify the requirements that shared passwords make painful:

• 1.3.3 requires network security controls between every wireless network and the cardholder data environment (CDE). The CDE is the set of systems that store, process, or transmit card data. Wireless traffic into the CDE must be denied by default. Identity-based access places authorized devices on a specific VLAN (virtual LAN) and denies everything else.
• 2.3.1 and 2.3.2 require you to change vendor default wireless keys. You must also change wireless encryption keys whenever someone who knew them leaves. With EAP-TLS no person knows a key, so the leaver trigger never fires.
• 4.2.1.2 requires strong cryptography for authentication and transmission on wireless networks carrying card data or connected to the CDE. PCI DSS has prohibited WEP since 2010. Mutual certificate authentication with WPA2-Enterprise or WPA3-Enterprise meets this requirement.
• 8.2.2 restricts shared and generic accounts to exceptional cases with documented justification. A network password shared by 200 staff members is hard to justify.
• 8.2.5 requires access for terminated staff to be revoked immediately. Disabling one account in your identity provider does that.
• 10.2.1 and 10.5.1 require audit logs, retained for 12 months with the most recent three months immediately available. RADIUS logs from 802.1X attribute each connection to a certificate or account.

Passwordless WiFi does not cover Requirement 11.2.1. That requirement asks you to test for authorized and unauthorized access points at least once every three months. It stays your job, as the limits section explains.

Does HIPAA require certificate-based WiFi?

No. The HIPAA Security Rule (45 CFR Part 164, Subpart C) is technology-neutral and names no wireless protocol. It sets standards and implementation specifications, some "required" and some "addressable." Addressable means you implement the specification where reasonable and appropriate. Otherwise you document why and adopt an equivalent alternative.

Certificate-based WiFi maps cleanly to the technical safeguards in §164.312:

• Unique identification, §164.312(a)(2)(i), required. Each device and person on the network has a distinct identity.
• Encryption and decryption, §164.312(a)(2)(iv), addressable. Per-session keys protect ePHI (electronic protected health information) moving over the air.
• Audit controls, §164.312(b), required. RADIUS logs record which identity joined, from which access point and when.
• Person or entity authentication, §164.312(d), required. A certificate proves the device is the one claimed. Tying it to an identity provider account extends that proof to the person.
• Transmission security, §164.312(e)(1). Integrity controls and encryption are both addressable specifications under this standard.

The administrative safeguards matter too. The risk analysis in §164.308(a)(1)(ii)(A) is where you record why your wireless controls are reasonable. Termination procedures in §164.308(a)(3)(ii)(C) are easier to evidence when disabling one account removes network access.

Watch the direction of travel. In January 2025 the US Department of Health and Human Services (HHS) published a proposed rule. It would remove most of the required-versus-addressable distinction. It would also make encryption and multi-factor authentication mandatory, with limited exceptions. It is a proposal, not a final rule. Certificate-based access already sits on the right side of it.

What does ISO 27001 say about wireless?

ISO/IEC 27001:2022 has no control called "wireless". Annex A lists 93 controls in four themes, and several apply directly to how staff join a network. ISO/IEC 27002:2022, the implementation guidance, addresses wireless under control 8.22. It notes that wireless perimeters are poorly defined. For sensitive environments, it suggests treating wireless access as an external connection until it passes a gateway.

The controls an auditor will test:

• 5.15 Access control and 5.18 Access rights. Rules for who may join, and how that access is provisioned and removed.
• 5.16 Identity management and 5.17 Authentication information. Identities and secrets managed across their lifecycle. A shared password is authentication information you cannot allocate to one person.
• 8.5 Secure authentication. Authentication technology suited to the sensitivity of the access.
• 8.15 Logging and 8.16 Monitoring activities. Logs that record events, and evidence that someone reviews them.
• 8.20 Networks security, 8.21 Security of network services and 8.22 Segregation of networks.
• 8.24 Use of cryptography.
• 5.19 and 5.23. Supplier relationships and cloud services, which apply if your authentication runs as a cloud service.

Organizations certified to ISO/IEC 27001:2013 had until 10/31/2025 to transition. If your Statement of Applicability still uses 2013 numbering such as A.9 or A.13, update it.

How the three frameworks map to passwordless WiFi

Control	Framework	What it asks	Shared password (PSK)	Certificate-based (EAP-TLS)
1.3.3	PCI DSS 4.0	Default-deny between wireless and the CDE	Every device on the key lands in one segment	Per-identity VLAN, deny by default
2.3.2	PCI DSS 4.0	Change wireless keys when anyone who knew them leaves	Rotate on every leaver, on every device	No person holds a key; revoke one certificate
4.2.1.2	PCI DSS 4.0	Strong cryptography for wireless authentication and transmission	Strength depends on passphrase quality	Mutual certificates, per-session keys
8.2.2	PCI DSS 4.0	Shared accounts only by documented exception	Shared by design	One credential per device or person
10.5.1	PCI DSS 4.0	12 months of logs, three months immediately available	Logs show MAC addresses only	Logs name the certificate or account
§164.312(a)(2)(i)	HIPAA	Unique identification (required)	Not met by the network credential	Met by design
§164.312(b)	HIPAA	Audit controls (required)	Weak attribution	Every session attributable
§164.312(e)(1)	HIPAA	Transmission security	Encrypted, but key known to all staff	Encrypted with keys no person knows
5.17	ISO 27001:2022	Authentication information allocated and managed	Cannot be allocated to one person	Issued, renewed and revoked per identity
5.18	ISO 27001:2022	Access rights provisioned and removed	Removal needs a network-wide key change	Removal follows the identity provider
8.22	ISO 27001:2022	Segregation of networks	One segment per key	Segment per role or device type

What evidence will an auditor ask for?

Auditors test design, configuration and operation. Design is your diagrams. Configuration is your exports. Operation is your logs and samples. Assemble the pack before fieldwork, not during it.

Evidence item	What it shows	PCI DSS 4.0	HIPAA	ISO 27001:2022
Network and data-flow diagrams showing staff, guest and CDE boundaries	Segmentation design	1.2.3, 1.2.4	§164.308(a)(1)	8.20, 8.22
Firewall or ACL rules between staff wireless VLANs and the CDE	Default-deny in practice	1.3.3	§164.312(e)(1)	8.22
SSID configuration export showing Enterprise mode and EAP-TLS	Strong authentication and encryption	4.2.1.2	§164.312(a)(2)(iv)	8.5, 8.24
Certificate policy: issuing CA, validity period, renewal, revocation	Lifecycle of authentication information	4.2.1.2	§164.312(d)	5.17
Terminated employee sample: account disable time against last network authentication	Timely revocation	8.2.5	§164.308(a)(3)(ii)(C)	5.18
RADIUS logs with retention settings	Attribution and retention	10.2.1, 10.5.1	§164.312(b)	8.15
Access point inventory and quarterly rogue scan results	Authorized and unauthorized access point control	11.2.1, 11.2.2	§164.308(a)(1)	8.16
Supplier certificates and contracts	Third-party assurance	12.8	§164.308(b) where the supplier handles ePHI	5.19, 5.23

How do you prove WiFi controls to an auditor?

Run the terminated employee test yourself first. It is the test a shared password cannot pass cleanly.

1. Export your HR terminated employee list for the audit period.
2. Select a sample, for example 10 to 25 terminated employees across sites.
3. For each, pull the account disable time from your identity provider.
4. Pull the last successful network authentication for that identity from RADIUS logs.
5. Any authentication after the disable time is a finding. Fix the cause before the auditor finds it.

On a PSK network, step four returns nothing useful. No log ties a connection to the leaver, so you cannot prove they stopped connecting.

Where does passwordless WiFi sit alongside what you already run?

You do not need new access points. 802.1X is a standard feature of enterprise access points. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet.

Purple Staff WiFi uses Identity-Based Networks. Network access follows your identity provider: Microsoft Entra ID, Okta or Google Workspace. Joiners get access when their account is created. Movers change network segment when their role changes. Leavers lose access when the account is disabled. That joiners, movers, leavers (JML) flow is what produces clean evidence for PCI DSS 8.2.5, HIPAA §164.308(a)(3)(ii)(C) and ISO 27001 control 5.18.

Your guest network stays separate. PCI DSS 1.3.3 applies to it as much as to staff networks: guest traffic into the CDE must be denied. Purple's Guest WiFi plans carry CCPA/CPRA and CCPA compliance for visitor data, as set out in Connect vs Capture.

For your supplier file, Purple holds ISO 27001 and Cyber Essentials certification and is CCPA/CPRA and CCPA compliant. Purple's own platform data shows 99.999% uptime across 80,000+ live venues. Your auditor will treat these as supplier assurance, not as proof of your own controls.

What does passwordless WiFi compliance look like in practice?

The three scenarios below are worked examples. Each states its assumptions, so you can rerun the arithmetic for your own estate.

A 200-room hotel: removing PCI key rotation

Situation. A 200-room hotel runs 140 staff on one PSK network. Front-desk PCs and restaurant tablets on that network reach the payment system, which puts it in PCI scope. Assume 30% annual staff turnover, so 42 leavers a year.

What was done. The staff network moved to 802.1X with EAP-TLS, tied to the hotel group's identity provider. Payment devices moved to a dedicated VLAN with default-deny rules from every other network. The guest network was isolated from both.

Outcome. Requirement 2.3.2 key rotations fall from 42 a year, each touching every staff device, to zero. Each leaver is removed by disabling one account. The leaver sample now has a log to compare against. Operators in Hotels with seasonal staff see the largest reduction, because turnover drives rotation.

A 40-store retail chain: shrinking the blast radius

Situation. A 40-store chain uses one PSK across every store for handheld stock scanners and back-office laptops. Store managers know the key. A former manager posts it online.

What was done. Managed laptops moved to EAP-TLS with certificates issued through device management. Scanners that could not hold certificates moved to iPSK, one key per device, on a restricted VLAN. Each store's access point inventory was documented under Requirement 11.2.2.

Outcome. The exposure from one leaked credential drops from 40 stores to one device. Revoking that device takes one action and leaves the other scanners connected. The chain can now show an assessor a per-device inventory instead of a single shared secret. The same pattern suits any Retail estate with mixed managed and headless devices.

A county health department: HIPAA attribution across 12 clinics

Situation. A US county health department runs 12 clinics. Clinicians use shared tablets to reach the electronic health record. Each clinic has its own network password, giving 12 shared credentials and no attribution in network logs.

What was done. Tablets received device certificates. Clinicians sign in with their identity provider account, so each session links a device to a person. RADIUS logs feed the department's log management. Retention was set against the six-year documentation period in §164.316(b)(2), where the department classes logs as documentation.

Outcome. Shared network credentials drop from 12 to zero. The risk analysis can record the encryption specification as implemented rather than documenting an alternative. Audit controls under §164.312(b) now show which person, on which device, joined which clinic network and when. Public-sector Healthcare teams answering to both HIPAA and state audit can reuse the same evidence pack. Crew devices on Trains follow the same model, with one identity per tablet across every carriage and depot.

What are the limits you should know about?

• It is not a compliance certificate. Passwordless WiFi satisfies specific controls. Scope, risk analysis and the rest of each framework remain yours.
• Rogue access points still need testing. PCI DSS 11.2.1 requires quarterly testing for authorized and unauthorized access points. Certificate-based access does not detect a rogue device plugged into a store switch.
• Certificates expire. You need a certificate authority, an enrollment method and a renewal process. A missed renewal disconnects every device whose certificate shares that expiry date.
• Not every device can hold a certificate. Printers, scanners and some clinical equipment cannot. Use iPSK or a segmented network, and document the exception.
• PEAP is not a shortcut. PEAP with passwords keeps password risk. If devices do not validate the server certificate, a fake access point can capture credentials.
• Logs only help if retained and reviewed. Set retention to 12 months for PCI DSS. Evidence a review cadence for ISO 27001 control 8.16.

What should you do next?

1. Classify every network name. Mark which ones touch the CDE, ePHI or neither. That decides which framework applies to each.\n2. Run the leaver test now. If you cannot complete it, you have found your first audit risk.\n3. Choose a credential per device class. EAP-TLS for managed laptops, cell phones, and tablets. iPSK for headless devices.\n4. Update your control documentation. Map the change in your Statement of Applicability, HIPAA risk analysis or PCI DSS scoping document.\n5. Pilot one site. Prove certificate enrollment, VLAN assignment and leaver revocation before rolling out across the estate.\n6. Build the evidence pack. Use the evidence table above as your checklist, three months before fieldwork.\n\n## Frequently asked questions\n\n### Is passwordless WiFi PCI compliant?\n\nPasswordless WiFi is not PCI compliant by itself, because PCI DSS assesses your environment rather than a product. It does satisfy Requirements 2.3.2, 4.2.1.2, 8.2.2 and 8.2.5 more cleanly than a shared password, and its RADIUS logs support Requirement 10. You still need default - deny controls between wireless networks and the cardholder data environment under 1.3.3, plus quarterly rogue access point testing under 11.2.1.\n\n### Does HIPAA require certificate - based WiFi?\n\nNo, HIPAA does not name any wireless technology. The Security Rule requires unique identification, audit controls, and person or entity authentication, and treats encryption as addressable. Certificate - based WiFi meets all of these by design, which makes your risk analysis easier to defend. A January 2025 HHS proposed rule would make encryption and multi - factor authentication mandatory with limited exceptions. It is a proposal, not a final rule.\n\n### What does ISO 27001 say about wireless?\n\nISO/IEC 27001:2022 has no wireless - specific control. Auditors test wireless against Annex A controls 5.15 to 5.18 for access and identity, 8.5 for secure authentication, 8.15 for logging, and 8.20 to 8.22 for network security and segregation. ISO/IEC 27002:2022 guidance under 8.22 suggests treating wireless access in sensitive environments as an external connection until it passes a gateway.\n\n### How do I prove WiFi controls to an auditor?\n\nYou prove WiFi controls with configuration, logs, and a leaver test. Bring network diagrams showing wireless and CDE boundaries, SSID exports showing Enterprise authentication, your certificate policy, 12 months of RADIUS logs, and quarterly rogue scan results. Then run a leaver sample, comparing each leaver's account disable time with their last successful network authentication. Any authentication after disablement is a finding.\n\n### Does Purple Staff WiFi work with our existing access points?\n\nYes, Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep your access points and switching. Purple connects network access to Microsoft Entra ID, Okta or Google Workspace, so moving away from a shared password does not require a rip-and-replace hardware project.

What about devices that cannot hold a certificate?

Use iPSK or a separate, segmented network for them. iPSK gives each device its own key on the same network name, so revoking one device leaves the rest connected. Place headless equipment such as printers and scanners on a restricted VLAN. Document the business justification in your risk analysis or Statement of Applicability, and review each exception at every audit cycle.

Does Purple's ISO 27001 certification make us compliant?

No, a supplier's certification does not transfer to you. Purple's ISO 27001, Cyber Essentials, GDPR and CCPA credentials are evidence for your vendor assessment under ISO 27001 controls 5.19 and 5.23 and PCI DSS Requirement 12.8. Your own scope, risk analysis, configuration and logs still need to meet each framework, and your auditor will test them directly.