Break-glass or emergency account
A named person answers for it and a second person checks each use; it is expected to sit unused between emergencies, so it is never read as dormant.
Who should own a break-glass or emergency account, and which ISO/IEC 27001, SOC 2 and PCI DSS clauses apply?
The clauses the checker cites on a break-glass or emergency account: ISO/IEC 27001 A.8.2, ISO/IEC 27001 A.5.16 and PCI DSS 8.2.2. Every clause it cites, across the seven regimes, is in the table below.
How the checker reads it
- It is a user account people sign in with: PCI DSS reads it under the user-account periods (8.2.6, 7.2.4, 8.3.9), never under 8.6.
- It needs a named person as owner; a blank owner, a team or a mailbox is finding 3, and an owner who has left by the staff list is finding 2.
- The type comes from your type column; when that is blank the checker reads the account name and labels the type assumed from the name, and any finding resting on it is read as a question by the reviewer.
- Dormancy is never read on a break-glass account: an emergency account that is used often is the question, not one that is quiet.
Findings that can apply
7 of 14- 2. Owner has left, or owner not recognised: Who owns this account now, and should it still exist?
- 3. No owner named, or a team named with no accountable person: Which one person is accountable for this account and can say what it is for?
- 5. Privileged, and orphaned or dormant: Who holds these rights today, and do they still need them?
- 6. Password or key not changed within the period, or never: When was this credential last changed, and who knows it?
- 8. Credential stored in code, a config file or a script: Can this credential move into a vault, and who has read the file it sits in?
- 10. Not reviewed within the interval: Who reviews this account, and when is the next review due?
- 12. Created with no approval recorded: Where is the request and the approval for this account?
Clauses
6 cited| Regime | Clause |
|---|---|
| ISO/IEC 27001 | ISO/IEC 27001 A.8.2 Privileged access rights |
| ISO/IEC 27001 | ISO/IEC 27001 A.5.16 Identity management |
| PCI DSS | PCI DSS 8.2.2 Shared and generic IDs only by exception |
| NIST SP 800-53 | NIST SP 800-53 AC-2 Account Management |
| CIS Controls | CIS Controls 6.5 Require MFA for Administrative Access |
| NIS2 | NIS2 Art. 21(2)(j) Multi-factor or continuous authentication, secured communications and secured emergency communications |
The first clause, set out
ISO/IEC 27001 A.8.2Privileged access rightsThe granting and use of privileged access rights are to be limited and managed. Purpose (stated in ISO/IEC 27002:2022): limits privileged access to authorized people, software components and services. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.2.
A line that reads as this type
the type column left blank, invented valuesbreakglass-01 | | directory | | yes