ASD ISM 1321 Enforce 802.1X EAP-TLS mutual authentication with other EAP methods disabled
What it says
802.1X with EAP-TLS is used for mutual authentication and key exchange; with all other EAP methods disabled on supplicants and authentication servers.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishNetwork access uses 802.1X with certificate-based EAP-TLS so device and server prove identity to each other, and every other EAP method is switched off on both clients and authentication servers.
802.1X is the gatekeeping protocol that decides whether a device is allowed onto a network port or wireless network. EAP-TLS is the strongest of the methods it can use: both the connecting device (the supplicant) and the authentication server present certificates, so each side proves who it is before any traffic flows. That same certificate handshake also produces the session keys that protect the connection afterwards, which is why the statement calls out both mutual authentication and key exchange. The second half of the control is just as important as the first. If weaker EAP methods (for example password-based ones) remain enabled on either the client or the server, an attacker can stand up a rogue access point or authentication server and coax devices into downgrading to a method they can capture or replay. Disabling everything except EAP-TLS on both the supplicants and the authentication servers removes that downgrade path. Doing it on only one side leaves the other side able to negotiate something weaker.
Free. Save your status, tasks and notes.
Why it matters
Without EAP-TLS enforced on both sides, devices can be tricked into authenticating to a rogue network or into using a password-based EAP method whose credentials can be harvested and reused. That gives an attacker a foothold on the internal network, allows interception of traffic, and undermines the confidentiality of the session keys that were supposed to protect wireless and wired connections.
How to implement
Network or identity engineers configure each authentication server (RADIUS or NPS) so that EAP-TLS is the only permitted EAP method, explicitly removing PEAP, EAP-TTLS, EAP-MSCHAPv2, LEAP, EAP-FAST and any other method from the allowed list, then export and version the resulting policy.
Endpoint administrators build the 802.1X supplicant profile in the device management platform (Intune, Jamf, Group Policy or equivalent) with EAP-TLS as the sole method, server certificate validation turned on and the trusted issuing CA pinned, and push it to every managed wired and wireless client.
PKI administrators issue a client certificate to each device (or user, as designed) from the organisation's CA and a server certificate to each authentication server, using automated enrolment and renewal so that mutual authentication does not fail when certificates approach expiry.
Network engineers set switch ports and wireless SSIDs to require 802.1X and point them at the EAP-TLS-only authentication servers, verifying with a test device that a connection using any other EAP method is rejected rather than falling back.
Security operations forward authentication server logs to the SIEM and create an alert for any EAP negotiation that proposes a method other than EAP-TLS, treating hits as either a supplicant configuration drift to correct or a rogue device to investigate.
Keep it running
Day to day, this control is about keeping three things in step: the supplicant profiles pushed to endpoints, the EAP method list on the authentication servers, and the certificates both sides rely on. Client and server certificates expire, so renewal must happen before expiry or devices will simply drop off the network. Any new device type, operating system build or authentication server added to the environment needs its EAP method list checked before it goes live, because vendor defaults usually leave several weaker methods on. Authentication server logs should be reviewed for any negotiation attempts using a non-TLS EAP method, since those indicate either a misconfigured supplicant or someone probing the network. Changes to supplicant or server EAP settings should go through change control so a "quick fix" to get a troublesome device connected does not quietly re-enable a weaker method.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current EAP method configuration exported from every authentication server that handles 802.1X.
Look at
Check the list of enabled EAP types on each server and whether any method other than EAP-TLS is still allowed or available as a fallback.
Good evidence
Every server shows EAP-TLS as the only enabled method, with all other EAP types explicitly disabled and the export dated recently.
- Check 2 of 5What an auditor asks for
Ask for
Request the 802.1X supplicant profile that is deployed to wired and wireless endpoints, along with deployment status from the device management tool.
Look at
Confirm the profile specifies EAP-TLS only, validates the server certificate against a named trusted CA, and has been applied to the full device fleet rather than a subset.
Good evidence
A single approved profile with EAP-TLS as the sole method is reported as applied to all in-scope devices, and no alternative profiles with weaker methods exist.
- Check 3 of 5What an auditor asks for
Ask for
Ask for evidence that both client and authentication server certificates are issued and managed through the organisation's PKI.
Look at
Review the certificate templates or issuance records, the expiry dates and the renewal mechanism to see that mutual authentication is actually certificate-based on both sides.
Good evidence
Client and server certificates chain to the internal CA, are within validity, and are renewed automatically before expiry.
- Check 4 of 5What an auditor asks for
Ask for
Request authentication server logs for a recent period covering successful and failed 802.1X attempts.
Look at
Look for the EAP method recorded against each authentication and for any attempts that proposed or succeeded with a method other than EAP-TLS.
Good evidence
All successful authentications show EAP-TLS, and any non-TLS attempts were rejected and investigated rather than accepted.
- Check 5 of 5What an auditor asks for
Ask for
Ask to observe or see the results of a test where a device configured for a weaker EAP method attempts to join the network.
Look at
Check whether the authentication server refuses the negotiation and the device is denied access, rather than being allowed to fall back or connect.
Good evidence
The test shows the connection rejected at the server, with a corresponding log entry, demonstrating that the restriction is enforced and not just documented.
Mappings
Closest match in ISO/IEC 27001: A.8.5, Secure authentication technologies and procedures, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.5.
ISM-1321 requires enforcing 802.1X using EAP-TLS mutual authentication for network access, with all other EAP methods disabled on supplicants and authentication servers. This relates to ISO/IEC 27001:2022 Annex A 8.5 because EAP-TLS is a specific secure authentication technology and associated procedure chosen to meet access restrictions. Annex A 8.5 is broader and technology-agnostic, while ISM-1321 prescribes an explicit mechanism and hardening requirement (disabling weaker EAP methods).
This control partially meets A.8.20.
ISM-1321 requires securing network access by enforcing 802.1X EAP-TLS mutual authentication and disabling alternative EAP methods to prevent downgrade or weaker authentication paths. This supports ISO/IEC 27001:2022 Annex A 8.20 by strengthening the security posture of networks and network devices through robust, certificate-based admission control at the access layer. Annex A 8.20 is broader (overall network/device security management and controls), whereas ISM-1321 is narrowly focused on 802.1X/EAP configuration for authentication and key exchange.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.