Skip to content
Networking
ASD ISMISM-1323

ASD ISM 1323 Requiring X.509 certificates for 802.1X network authentication

What it says

X.509 certificates are required for devices and human users authenticating to networks using 802.1X.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Devices and people joining a network through 802.1X must prove who they are with an X.509 certificate, not a password or shared key.

802.1X is the standard that makes a network switch port or wireless access point refuse to pass traffic until whatever is connecting has authenticated. That authentication can be done in several ways, and this control says which one to use: an X.509 certificate. Every device that joins the network, and every person who authenticates to it, must present a certificate issued by an authority the organisation trusts. This matters because the weaker 802.1X methods lean on secrets that can be copied. A username and password can be phished, guessed or reused from another breach, and a shared network key can be lifted from one laptop and typed into any other. A certificate is bound to a private key that stays on the device or in the user's credential store, so an attacker cannot simply learn it and reuse it elsewhere. Requiring certificates for both devices and human users closes the two common gaps: an unmanaged or rogue device plugging into a port, and a legitimate device being driven by someone who has stolen a password. The control applies to networks in general wherever 802.1X is the gate, whether the connection is wired or wireless.

Why it matters

If certificates are not required, the network's admission control rests on passwords or pre-shared keys that can be phished, brute-forced or copied between devices. An attacker with a stolen credential, or a personal laptop that has been given the shared key, can join the internal network and reach whatever it exposes, and the organisation gains little assurance about which device or person is actually on a given port or wireless session. 802.1X then exists in name only, and any segmentation or access decisions built on top of it are unreliable.

How to implement

  1. Network and identity teams identify every network segment, switch and wireless SSID that uses 802.1X for admission, and record which EAP method each one currently accepts so the scope of the change is known.

  2. The PKI or identity team stands up or extends an internal certificate authority with separate templates for device certificates and human-user certificates, and configures the RADIUS or network policy server to trust that authority.

  3. Endpoint administrators configure automatic enrolment (for example through the device management platform or group policy) so every managed device receives its certificate at build time and renews it automatically before expiry.

  4. The identity team issues user certificates to human users through the same enrolment path, and configures the network policy server to accept only certificate-based EAP (EAP-TLS), disabling password-based EAP methods such as PEAP-MSCHAPv2 rather than just lowering their priority.

    Wireless networks secured with a pre-shared key do not use 802.1X and are handled separately from this policy.

  5. Network and identity teams tie certificate revocation into the leaver and device-decommissioning processes, so a revoked user or device certificate is rejected by the policy server the next time it tries to authenticate.

Keep it running

In practice this control lives in three places: the certificate authority that issues device and user certificates, the enrolment mechanism that gets those certificates onto endpoints and into user credential stores, and the RADIUS or network policy server that the switches and access points consult. The policy server should be configured so that only the certificate-based EAP method, EAP-TLS, is accepted and password-based EAP methods are disabled, not merely deprioritised.

Day to day, the main work is keeping certificates flowing: new devices need one before they can join, replacements and rebuilds need re-enrolment, and expiring certificates need to renew ahead of time or the device drops off the network. Departing users and decommissioned devices need their certificates revoked so the policy server stops accepting them. Expect some support load when a certificate silently expires or a device is imaged without one, so give the service desk a clear procedure for checking certificate status and re-enrolling. Keep the network policy server's authentication logs, as they are both your troubleshooting aid and your evidence that only certificate-authenticated devices and users are getting through.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the 802.1X authentication policy configuration from the RADIUS or network policy server.

    Look at

    Check which EAP methods are enabled and whether any password-based EAP methods (for example PEAP-MSCHAPv2) remain active for the in-scope 802.1X networks.

    Good evidence

    Only certificate-based methods are enabled, and password-based methods are explicitly disabled rather than simply ordered below them.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the list of networks, switches and wireless SSIDs where 802.1X is enforced, alongside the organisation's network inventory.

    Look at

    Compare the two to see whether any 802.1X-gated network has been left on a non-certificate method or outside the policy.

    Good evidence

    Every network that uses 802.1X for admission requires certificates for both devices and human users, with no undocumented exceptions.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the certificate templates and enrolment configuration used for device certificates and user certificates.

    Look at

    Confirm there are distinct templates for devices and for human users and that enrolment is automated for managed endpoints.

    Good evidence

    Both devices and people receive certificates from a trusted internal authority through a repeatable enrolment process, not manual one-off issuance.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for a sample of recent authentication logs from the network policy server.

    Look at

    Look at the authentication method recorded against successful sessions and whether any succeeded using a password-based EAP method rather than a certificate.

    Good evidence

    Successful authentications for the in-scope networks all show a certificate-based method, and failures for non-certificate attempts are visible.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the certificate revocation procedure and evidence of recent revocations for departed users or retired devices.

    Look at

    Check whether revocation is linked to leaver and decommissioning workflows and whether the policy server checks revocation status.

    Good evidence

    Revoked certificates are rejected at the next authentication attempt, and there are records showing the process has actually been exercised.

Mappings

Closest match in ISO/IEC 27001: A.8.5, Secure authentication technologies and procedures, which this control partially meets.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.8.5Secure authentication technologies and proceduresPartially meets
  • A.8.20Network and network devices securityPartially meets
  • A.8.21Security of network servicesPartially meets

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.