ASD Essentials IT.PRO-13.2 Store Keys, Secrets and Tokens in Approved, Access-Controlled Repositories with MFA
What it says
Store authentication keys, secrets and tokens in approved secure repositories with access controls, including MFA.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeeps passwords, keys, tokens and other secrets in an approved secure store, with tight access controls and multi-factor sign-in.
Passwords, keys and tokens let people and systems prove who they are. To meet this, all of them are kept in an approved secure store, such as a password manager or secrets vault. None are left in files or spreadsheets. Only the people and systems that need a secret can reach it. Opening the store needs multi-factor authentication (MFA), and every access is logged and reviewed.
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
- Business systems
- User devices (does not apply)
Why it matters
Passwords left in scripts, spreadsheets or shared drives are easy to collect. One admin password or app key lets an attacker pose as a trusted user or system. A poorly protected store lets one stolen login unlock every secret, unnoticed.
How to implement
The head of security should approve secure stores for all secrets and publish a standard requiring them and banning plain-text passwords.
Where you run an internal certificate authority, keep its private keys in a hardware security module (a tamper-proof device).
System owners should list the keys, secrets and tokens their systems depend on and move them into the approved stores.
Record anything not yet moved as a risk-assessed exception with an owner.
Store administrators should grant access by role or by details such as project, so each person or app gets only the secrets it needs.
Limit store administration to a small named group.
Identity administrators should require MFA on every way into each store, phishing-resistant where possible, such as a security key.
Cover the console, apps, command line, programming interface and emergency access, and give each gap an owner to close it.
Security operations should log all store access centrally and review it on a set routine.
Look for bulk downloads of secrets, unexpected accounts and policy changes, and investigate anything unexplained.
Keep it running
Make the approved stores the default for every new system, connection and account. When a password or key turns up elsewhere, move it in, delete the old copies and change it if it may have been exposed. Follow ASD's priority order: internet-facing and sign-in systems first (the stores themselves count as sign-in systems), then critical and admin systems, then business systems. This action does not cover staff devices. Update access promptly when people change roles.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the secrets storage standard and a list showing where each secret is held.
Look at
Whether secrets still sit in plain-text files or spreadsheets, or whole types or ASD domains skip the stores.
Good evidence
Every in-scope key, secret and token is held in an approved store.
- Check 2 of 5What an auditor asks for
Ask for
Ask owners of sampled systems in each ASD domain to show where their secrets are held.
Look at
Whether copies remain in settings files or scripts, or secrets sit outside a store with no recorded exception.
Good evidence
Each secret comes from a store, and every exception is recorded and risk-assessed.
- Check 3 of 5What an auditor asks for
Ask for
Request each store's access rules, members and administrator list.
Look at
Whether broad access lets whole teams read every secret, or old members and one-off permissions remain.
Good evidence
Access by role or other details limits each person and system to the secrets it needs.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the MFA settings and a list of every way into each store.
Look at
Whether any user, store or way in lacks MFA, and whether each gap is recorded with a fix.
Good evidence
MFA is required on every relevant way in, for every user and store.
- Check 5 of 5What an auditor asks for
Ask for
Request recent store access logs, the review records and any investigations raised.
Look at
Whether logging is on for every store, and whether logs are actually reviewed or just collected.
Good evidence
All access is logged and routinely reviewed, and suspicious access is investigated.
ASD indicators of good practice (9)
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-1Credentials are stored in plaintext, spreadsheets, shared drives or other unapproved locations as standard practice.
- NE-2No approved secure repository is in use to store authentication keys, secrets and tokens.
- NE-3Access to credential stores is neither controlled nor audited.
- NE-4Access controls such as MFA are not enabled for authentication to secure repositories.
Partially effective(3)
- PE-1An approved secure repository is in use but does not cover all authentication keys, secrets and tokens within scope.
- PE-2Access controls for secure repositories are in place but access logging is not enabled or not reviewed.
- PE-3MFA is enforced for some, but not all, applicable users, repositories or authentication pathways, and the remaining exceptions are documented and subject to remediation.
Fully effective(2)
- FE-1Authentication keys, secrets and tokens within scope are stored in approved secure repositories, with any authorised exceptions documented, risk-assessed and managed in accordance with organisationally defined requirements.
- FE-2Access to secure repositories is restricted using attribute or role-based access controls, MFA is enforced for all applicable authentication pathways, and access is logged and reviewed and investigated where necessary.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of Authentication Information, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.17.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories protected by access controls, including MFA. This is a specific implementation of the controlled management of authentication information required by Annex A 5.17, addressing how that information is securely held. Annex A 5.17 is broader, also covering how authentication information is allocated and how personnel are advised to handle it.
This control partially overlaps A.8.24.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories protected by access controls, including MFA. Secure storage of keys is part of the cryptographic key management required by Annex A 8.24, so the two share common ground for cryptographic authentication keys. Annex A 8.24 also sets rules for the effective use of cryptography across the wider key life cycle, while IT.PRO-13.2 also extends to secrets and tokens that are not cryptographic keys.
ASD Essential Eight: 2 mappings
- E8-MF-ML3.1Multi-factor authentication is used to authenticate users of data repositoriesPartially overlaps
This control partially overlaps E8-MF-ML3.1.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories with access controls and MFA; E8-MF-ML3.1 requires MFA for users of data repositories, overlapping on the MFA part of controlling repository access.
This control partially overlaps E8-MF-ML3.3.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories with access controls and MFA; E8-MF-ML3.3 requires the MFA used for data repository users to be phishing-resistant, a stronger form of that MFA protection.
ASD Information Security Manual: 2 mappings
This control partially overlaps ISM-1402.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories with access controls and MFA; ISM-1402 names specific protections for stored credentials: a password manager, a hardware security module, or salting, hashing and stretching.
This control partially overlaps ISM-1957.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories with access controls and MFA; ISM-1957 requires Microsoft AD CS certification authority private keys to be protected by a hardware security module, a narrower case for one key type.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.