The Shared Credential and the MFA Fig Leaf

Partially - and not the part that matters most.

What MFA helps with: if the laminated card is photographed, or the password is reused on a forum, a stolen password alone no longer authenticates. That removes a large credential-theft path, especially from off-network access.

What it does not fix:

• Accountability / non-repudiation. All 14 technicians still authenticate as one identity. Every action in the logs is attributable to 'the shift,' not a person. That is the core audit finding, and MFA makes it no better.
• Least privilege. The account holds Domain Admin for tasks that need, at most, delegated rights over user objects and print queues. A shared Domain Admin credential is the highest-value target on the domain.
• Offboarding. Two contractors leave in 90 days. With a shared password, 'removing' them means changing the credential for all 14 or doing nothing.
• The MFA enrollment itself. Someone must hold the token or the shared secret, and whoever does is effectively the account owner - an undocumented single point of trust.

Judgment: the proposal reduces the likelihood of one attack path while preserving the structural defect. It is a compensating control at best, and only if paired with named accounts.

Target state: every technician uses a named account with standard rights; privileged work is checked out from a vault.

1. Remove Domain Admin from tier-1 work (technical, preventive). Highest reduction per unit of effort. Replace with delegated permissions scoped to the OU holding workstations and the print server. Nothing else on this list matters much while the credential stays this powerful.
2. Named accounts plus vaulted just-in-time elevation (technical/managerial, preventive). Admin rights granted per ticket, time-boxed to roughly 60 minutes, session recorded. This delivers accountability - the actual audit finding - and shrinks standing privilege.
3. Retire the shared credential and the card (managerial/operational, preventive). Use a managed service account only where an application genuinely needs one, with a long random secret rotated automatically.
4. Contractor hygiene (managerial, preventive). Accounts with expiry dates aligned to contract end, sponsor-verified, included in the quarterly access review.
5. Detective layer (technical, detective). Alert on break-glass use and on elevation outside ticket hours; review monthly.

Largest single reduction: item 1. An over-privileged shared credential is a domain compromise waiting for one phish, and it is also the cheapest fix on the list.

Availability is a legitimate requirement. The answer is a controlled exception, not a permanent shared credential.

• Break-glass accounts: one per shift lead, named, with a long random passphrase in a sealed envelope in a physical safe and a FIDO2 key held by the on-call manager. Use triggers an immediate high-severity alert and a mandatory post-use note.
• Two-person rule: break-glass use needs the shift lead plus one other technician to acknowledge. It takes 30 seconds and removes casual use.
• Vault resilience: clustered nodes, a documented offline recovery procedure, a printed recovery kit held by the IT director, and a quarterly failover test during a maintenance window. An untested break-glass procedure is theater.
• Keep the blast radius small: break-glass accounts should not be Domain Admin. In an outage the genuine need is resets and unlocks, which delegated rights already cover.
• Measure it: more than a handful of break-glass events per quarter means the vault is unreliable, not that the control is working.

Present this to the risk committee as a documented exception with an owner, a compensating-control rationale, and a review date.