Document the technical reason MFA cannot be used, replace it with compensating controls such as narrow permissions, network limits, secret rotation and logging, name an owner, and review on a short clock. The exception should say what the account can do, from where, and how misuse would be noticed.
This is common for service accounts, batch jobs and old integrations. MFA is built for people at a keyboard, and a script has no phone to tap.
First, confirm it is really impossible
Before writing the exception, check for alternatives. Many systems offer non-interactive, stronger options than a shared password:
- Certificate or key based authentication.
- Short-lived tokens issued by an identity provider.
- Workload identity from the platform, so no stored secret exists.
If any of these is available, migrating beats excepting. Put the migration on the exception as the exit plan.
The record
| Field | What to write |
|---|---|
| Account | Name, system, type (service, shared, break-glass) |
| Why MFA is not possible | The specific technical limit, with a reference |
| Permissions | What the account can access, kept to the minimum |
| Network limits | Source addresses or private network only |
| Secret handling | Stored in a vault, rotated on a schedule |
| Monitoring | Logs of use, alerts on logins from unexpected places |
| Owner and approver | Two different people |
| Expiry and exit plan | Date, plus the migration that retires the exception |
Compensating controls that carry weight
Controls should reduce the specific risk of a stolen credential. Restricting login to known source addresses means a leaked password is useless elsewhere. A vault with rotation shortens the life of any leak. Alerts on use outside the expected pattern turn silent misuse into a page. A control that merely says "strong password" does not add much.
Interactive logins are different
If a human signs in with the account, be stricter. Shared human accounts without MFA are hard to defend. Give each person an individual identity with MFA, and keep any non-interactive account separate from them.
Review cadence
Choose 90 days or less. Each review asks whether a better authentication option now exists, whether the permissions can shrink, and whether the logs show anything odd. Keep a sample of the log review as evidence.
How auditors read it
An auditor wants to see that the exception is rare, specific, owned and temporary. A register with 40 permanent service account exceptions suggests a gap in your identity design, not a handful of unavoidable cases.
Where Safeguard fits
Safeguard's agent identity capability and asset discovery help inventory non-human identities and where they run, which is the starting list for finding accounts like these.
Quick check
Is a long random password enough as a compensating control?
Rarely on its own. Pair it with network restriction, rotation and monitoring so a leak has limited value and short life.
Can a break-glass account skip MFA?
Break-glass accounts are a special case with their own controls. Record them as exceptions with tight monitoring and test them on a schedule.
Last reviewed: 19 October 2026.
