What should organisations do when passwords are still needed for critical access?

Why This Matters for Security Teams

When passwords are still required for critical access, the risk is not the password format itself but the way long-lived credentials behave under pressure: they are copied, cached, reused, and exposed far beyond the original approval path. That is why password workflows for privileged or break-glass access should be treated as a controlled exception, not a normal operating model. Current guidance suggests aligning these workflows with the same discipline used for non-human identities: short exposure windows, tight entitlement scope, and continuous auditability.

This is especially important because secrets and credentials remain a major attack path across enterprise environments. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage. OWASP’s OWASP Non-Human Identity Top 10 also frames weak lifecycle control as a core identity risk, which applies directly when passwords are used as emergency access material.

In practice, many security teams discover password sprawl only after a recovery account, contractor login, or emergency admin password has already been reused in a place no one expected.

How It Works in Practice

The operational goal is to make password use behave like a just-in-time credential, even if the underlying factor is still a password. That means the password should be stored in a secrets manager or vault, released only for an approved purpose, and removed from active use as soon as the task ends. The access path should be time-bound, logged, and tied to a specific operator, system, or incident ticket. This is consistent with the broader lifecycle and rotation guidance in NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks.

Practitioners usually need four controls working together:

• Vault the password instead of embedding it in code, runbooks, or shared documents.
• Release it only through approved recovery or PAM workflows, with approval and justification recorded.
• Constrain the account behind the password with least privilege, so the secret does not become a shortcut to broad access.
• Rotate or invalidate the password immediately after use, especially after break-glass events or shared access.

For implementation, organisations should also prefer temporary access mechanisms around the password, such as session recording, step-up approval, and time-limited entitlements. NIST’s identity guidance and the Zero Trust model reinforce that access should be re-evaluated at the point of use, not assumed durable. That is also why teams increasingly pair password-controlled workflows with policy checks from NIST SP 800-207 and lifecycle discipline from the broader NHI management model.

Where possible, passwords should be treated as a fallback for recovery or legacy integration only. These controls tend to break down when the password is shared across multiple systems or held by a privileged service account that cannot be cleanly rotated without outage risk.

Common Variations and Edge Cases

Tighter password control often increases operational overhead, requiring organisations to balance rapid recovery against stricter change discipline. That tradeoff is real in environments such as legacy mainframes, third-party admin portals, or regulated production systems where passwordless alternatives are not yet available. Best practice is evolving, but there is no universal standard for eliminating passwords in every critical path today.

Edge cases usually fall into three buckets. First, break-glass accounts may need to bypass normal controls during incidents, but the exemption should still be audited, time-boxed, and rotated immediately after use. Second, shared vendor access often creates ambiguity over ownership, so the password must be governed as a high-risk secret with explicit renewal and offboarding rules. Third, recovery credentials used by automation can be mistaken for ordinary service accounts; in those cases, the process should be reviewed with the same rigor as NHI exposure and rotation practices described in the 52 NHI Breaches Analysis.

If a password must remain in the workflow, the safest posture is to assume it will eventually be exposed and design the process so that exposure has minimal blast radius, minimal duration, and a clear forensic trail.

Related resources from NHI Mgmt Group

• Why do passwords still persist even when organisations know they are risky?
• How can organisations run FIDO and CBA together without creating access sprawl?
• How can organisations tell whether contextual access decisions are improving governance?
• How do organisations know whether access friction is becoming a retention risk?