ASD ISM 1322 Using evaluated supplicants, authenticators and authentication servers for 802.1X
What it says
Evaluated supplicants, authenticators and authentication servers are used for 802.1X authentication implementations.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery component of an 802.1X set-up (the client supplicant, the switch or access point acting as authenticator, and the authentication server) must be an evaluated product.
802.1X is the mechanism that decides whether a device is allowed onto a network port or wireless network before it gets any access. It relies on three parts working together: the **supplicant** (the software on the connecting device that presents credentials), the **authenticator** (the switch or wireless access point that gates the connection) and the **authentication server** (the back-end that checks the credentials and tells the authenticator to allow or deny). This control requires that all three of those components are **evaluated products**. In the ISM, "evaluated" has a specific meaning: the product has completed a Common Criteria evaluation under the Australasian Information Security Evaluation Program (AISEP) or an equivalent recognised scheme and appears on ASD's Evaluated Products List (EPL), rather than simply being whatever came bundled with the hardware or a free download. A vendor penetration test or a general third-party certification does not make a product evaluated in this sense. Why it matters: 802.1X is a gatekeeper. If any one of the three components has weak cryptography, a flawed protocol implementation or a hidden vulnerability, the whole access-control decision can be bypassed or spoofed. A poorly built supplicant might leak credentials to a rogue access point, an unevaluated authenticator might fall open under malformed traffic, and a weak authentication server might accept forged responses. Using evaluated components gives assurance that each link in the chain actually performs the authentication function it claims to, so the network perimeter cannot be walked around at the very point where it is supposed to be enforced.
Free. Save your status, tasks and notes.
Why it matters
If unevaluated supplicants, authenticators or authentication servers are used, the organisation has no independent assurance that its 802.1X authentication works as intended. A flaw in any single component can let an unauthorised device join the network, allow credentials to be captured by a rogue access point, or let an attacker impersonate the authentication server. Because 802.1X is often the only barrier between an untrusted device and internal systems, a weak component can quietly undermine network segmentation, expose internal services and make the access-control logs unreliable as evidence of who was actually on the network.
How to implement
Network architecture owner: inventory every 802.1X implementation (wired switch ports and wireless networks) and, for each, record the supplicant, authenticator and authentication server product, version and firmware in a single register.
Procurement and security teams: add a mandatory check to purchasing and change approval that confirms the evaluation status of any switch, access point, wireless controller, authentication server or supplicant before it enters the 802.1X path.
Endpoint engineering team: define the evaluated supplicant in the standard operating environment build for workstations, laptops and mobile devices and enforce it through configuration management so unevaluated clients cannot be substituted.
Network operations team: pin authenticators and authentication servers to evaluated versions in the patch and firmware baseline, and route any move to a version outside that baseline through change control with a documented risk decision.
Security governance lead: establish an exception process for any 802.1X component that is not evaluated, requiring a recorded risk assessment, an owner, compensating controls and an expiry date, and review open exceptions on a regular schedule.
Keep it running
Day to day this control is mostly about **procurement and configuration discipline**:
- When a new switch, wireless controller, access point or RADIUS/authentication server is purchased or upgraded, the evaluation status of the product (and the specific version or firmware) is checked against ASD's Evaluated Products List before it is put into the 802.1X path.
- Endpoint build standards specify which supplicant is used on workstations, laptops and mobile devices, so that an evaluated supplicant is not silently replaced by a built-in or third-party client that has not been evaluated.
- Firmware and software updates are tracked against the evaluated version, because an evaluation typically applies to particular versions. Moving to an unevaluated version needs a conscious decision and record.
- The network team keeps an inventory that maps every 802.1X deployment (wired and wireless) to the three components in use and their evaluation status, so gaps are visible rather than discovered during an assessment.
- Where an evaluated component is temporarily unavailable (for example a lab, a pilot or a vendor outage), the exception is recorded, risk-assessed and time-limited rather than allowed to become permanent.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register of 802.1X implementations listing the supplicant, authenticator and authentication server used for each wired and wireless network.
Look at
Check that every implementation names all three components with product, version and firmware, and that the evaluation status of each is recorded.
Good evidence
The register is complete, current and shows each component as an evaluated product with the evaluated version in use, with no unexplained blanks.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the procurement or change approval records for recently purchased or upgraded switches, access points, wireless controllers or authentication servers.
Look at
Look for evidence that evaluation status was verified as part of approval before the product was placed in the 802.1X path.
Good evidence
Approval records show a specific evaluation check with the reviewer, date and outcome, rather than a generic security sign-off.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the endpoint build standard or configuration management policy that defines the 802.1X supplicant deployed to devices.
Look at
Confirm that the standard names an evaluated supplicant and that configuration reports from a sample of devices show that supplicant actually in use.
Good evidence
Sampled workstations, laptops and mobile devices all run the evaluated supplicant specified in the standard, with no unmanaged or alternative clients present.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the firmware and software baseline for authenticators and authentication servers, plus recent change records for version upgrades.
Look at
Compare the versions deployed on a sample of devices and servers to the evaluated versions in the baseline, and check that any deviation went through change control.
Good evidence
Deployed versions match the evaluated baseline, and any upgrade outside it has a recorded risk decision rather than having occurred silently.
- Check 5 of 5What an auditor asks for
Ask for
Ask how any 802.1X component that is not an evaluated product is recorded and tracked, for example in an exceptions register.
Look at
Check that each exception has a risk assessment, an accountable owner, compensating controls and an expiry or review date.
Good evidence
Exceptions are few, time-limited, actively reviewed and closed once an evaluated component is in place, with none that have quietly become permanent.
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-1322 requires that, in an IEEE 802.1X network access control deployment, the three critical authentication components (supplicant on the endpoint, authenticator such as a switch/WAP, and the AAA/RADIUS authentication server) are all evaluated products. This relates directly to ISO/IEC 27001:2022 Annex A 8.5 because 802.1X/EAP is a secure authentication technology and ISM-1322 is a concrete implementation constraint to ensure the authentication technology is trustworthy (via product assurance) when used to enforce access restrictions at the network edge. Annex A 8.5 is broader and technology-agnostic (covers any authentication technologies and procedures), whereas ISM-1322 is a specific assurance requirement for a specific authentication architecture (802.1X) rather than covering authentication procedures more generally.
This control partially meets A.8.20.
ISM-1322 requires use of evaluated 802.1X ecosystem components to provide trustworthy authentication for wireless network access. This aligns with Annex A 8.20's requirement to secure, manage and control networks and network devices to protect information. ISM-1322 focuses specifically on WLAN access control via 802.1X and assurance of component evaluation, while Annex A 8.20 covers a much wider set of network security controls (e.g. configuration, management, and broader device security).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.