ASD Essentials IT.PRO-13.5 Disable Legacy Authentication Protocols and Restrict, Monitor and Decommission Exceptions
What it says
Disable legacy authentication protocols or, where this is not feasible, restrict and monitor their use, apply compensating controls and establish a time-bound decommissioning plan.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSwitches off older, weaker sign-in methods, and puts limits, monitoring, extra safeguards and a removal date on any that must stay.
Many systems still accept older ways of signing in. Some send passwords in readable form or use weak encryption, and many cannot ask for multi-factor authentication (MFA). For example, an old email setting may accept just a password. To meet this, the organisation finds these methods on every system and turns them off. Any still needed is tightly limited, watched, given extra safeguards and a removal date, with the risk formally accepted.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
Why it matters
Attackers try common passwords against sign-in paths that cannot ask for MFA, then sign in as real users. Readable or weakly encrypted passwords can be captured, cracked or reused. This gives attackers a way in that can spread to sign-in and admin systems.
How to implement
The identity and infrastructure teams should find which old sign-in methods are switched on and used on every in-scope system.
Use settings reviews, sign-in logs and network traffic, and keep each in an up-to-date list.
System owners should switch off each old method, such as NTLM and Telnet (older network sign-ins), basic email sign-in and any that let captured sign-ins be reused.
Use central settings and build standards, trying report-only (audit) mode first where available.
The system owner should write down why a method cannot yet be switched off and get the risk accepted.
Limit it to the systems and accounts that need it, and add extra safeguards such as a separate network zone.
Security operations should log every use of a kept method centrally.
Alert on unexpected accounts or sources, bursts of failed sign-ins and any use of a method marked as switched off.
The system owner should agree a removal plan for each kept method, with an accountable owner and target date.
Record it in the risk register, and have the risk committee review it regularly.
Keep it running
Treat this as ongoing upkeep, not a one-off project. Refresh the list of old sign-in methods on the set cycle. New systems, vendor defaults and settings changes can quietly switch one back on. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. If a removal date slips, the risk owner makes a fresh decision, recorded in the risk register.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the latest review of old sign-in methods, its list and the in-scope system list.
Look at
Whether the review covered every in-scope system, and whether the list has been kept current.
Good evidence
A current list shows old sign-in method use across all in-scope systems.
- Check 2 of 5What an auditor asks for
Ask for
Request settings evidence for sample systems, such as a directory server, website and laptop.
Look at
Whether old, readable or weak methods stay on without a written, risk-accepted exception.
Good evidence
Old methods are off everywhere except written, risk-accepted exceptions.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the kept methods and, for a sample, their set limits and extra safeguards.
Look at
Whether limits exist only on paper, or kept methods have no extra safeguards.
Good evidence
Each kept method is limited to the systems and accounts that need it, with working safeguards.
- Check 4 of 5What an auditor asks for
Ask for
Request sign-in logs, monitoring rules and recent alerts for the kept methods.
Look at
Whether logs show use outside the exceptions, monitoring misses some, or alerts go unreviewed.
Good evidence
Every kept method is monitored the same way, and alerts are reviewed and acted on.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the removal plans, risk register entries and latest risk reviews for kept methods.
Look at
Whether exceptions lack a timeline or owner, or missed dates have no fresh risk decision.
Good evidence
Each exception has a tracked removal date and is reviewed regularly in the risk register.
ASD indicators of good practice (12)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(4)
- NE-1Legacy authentication protocols that cannot enforce modern authentication controls remain enabled and in active use without restriction.
- NE-2No assessment has been conducted to identify which legacy authentication protocols are in use within the environment.
- NE-3Authentication mechanisms transmitting credentials in cleartext or using weak cryptographic primitives remain enabled and no action has been taken to disable them.
- NE-4Where legacy protocols are retained, no compensating controls, no monitoring and no decommissioning timelines are in place.
Partially effective(4)
- PE-1Legacy authentication protocols have been identified and are partially restricted but some remain enabled across systems within scope without justification.
- PE-2An assessment has been conducted but does not cover all in-scope systems, or the inventory of legacy protocols in use is not maintained.
- PE-3Some weak authentication mechanisms have been disabled but others remain enabled without documented justification or remediation plan.
- PE-4Compensating controls exist for some retained legacy protocols but monitoring is inconsistent or decommissioning timelines are not defined.
Fully effective(4)
- FE-1Legacy authentication protocols that cannot enforce modern authentication controls have been identified and disabled across systems within scope, excluding documented and risk accepted exceptions.
- FE-2An assessment of legacy authentication protocol use has been conducted across in-scope systems and the inventory is maintained.
- FE-3Where retention is necessary, compensating controls are applied and decommissioning timelines are recorded and tracked.
- FE-4Ongoing use of legacy authentication protocols is regularly risk reviewed, accepted and recorded in the organisation’s risk register.
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.
IT.PRO-13.5 requires legacy authentication protocols to be disabled or, where that is not feasible, restricted, monitored, covered by compensating controls and placed on a time-bound decommissioning plan. Removing weak authentication mechanisms is a specific way of ensuring that only secure authentication technologies are used, as Annex A 8.5 requires. Annex A 8.5 is broader, covering the selection and implementation of secure authentication technologies and procedures in general.
This control partially meets A.8.9.
IT.PRO-13.5 requires legacy authentication protocols to be disabled or, where that is not feasible, restricted, monitored, covered by compensating controls and placed on a time-bound decommissioning plan. Disabling these protocols is a specific security configuration that falls within the configuration management required by Annex A 8.9. Annex A 8.9 is broader, covering how all configurations are established, documented, implemented, monitored and reviewed, while IT.PRO-13.5 adds exception handling for protocols that cannot yet be removed.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-0380.
IT.PRO-13.5 requires legacy authentication protocols to be disabled or, if not feasible, restricted, monitored and scheduled for decommissioning; ISM-0380 requires unneeded operating system accounts, components, services and functionality to be disabled or removed, a broader rule sharing that step.
This control partially overlaps ISM-1055.
IT.PRO-13.5 requires legacy authentication protocols to be disabled or, if not feasible, restricted, monitored and scheduled for decommissioning; ISM-1055 requires LAN Manager and NT LAN Manager authentication methods to be disabled, a specific case naming two methods.
This control partially overlaps ISM-1603.
IT.PRO-13.5 requires legacy authentication protocols to be disabled or, if not feasible, restricted, monitored and scheduled for decommissioning; ISM-1603 requires authentication methods open to replay attacks to be disabled, targeting weak methods by replay risk rather than age.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.