What breaks when on call access is managed with manual approval and shared credentials?

Why This Matters for Security Teams

Manual approval and shared credentials fail because on-call access is not a normal user-login problem. It is an operational control problem: urgent work must happen fast, but the access path still needs traceability, least privilege, and revocation. When teams reuse one credential across responders, they lose attribution, cannot prove who changed what, and often keep access open longer than intended to avoid blocking incident response.

This pattern also undermines the access models that most audit and security programmes assume. Static approvals map poorly to real on-call conditions, where a responder may need access only for one service, one cluster, or one incident window. NHI guidance increasingly points to dynamic, short-lived access instead of shared standing credentials, as described in the Ultimate Guide to NHIs and the Ultimate Guide to NHIs.

In practice, many security teams discover the weakness only after an incident review shows that nobody can reliably prove which responder used the shared secret.

How It Works in Practice

Better on-call access design starts by separating approval from credential sharing. A responder should authenticate as an individual, then receive time-bound access that is tied to a schedule, a ticket, or an incident declaration. The access should be specific to the task, not a reusable password or token that can be handed around informally.

Current guidance suggests using short-lived credentials, just-in-time elevation, and policy checks at request time rather than pre-approving broad standing access. That lines up with the OWASP Non-Human Identity Top 10 and NIST’s emphasis on least privilege in the NIST Cybersecurity Framework 2.0. In operational terms, the control set usually includes:

• Individual identity for each responder, never a shared team account.
• JIT access with a short TTL that expires automatically when the window ends.
• Approval tied to a service owner, incident commander, or break-glass policy.
• Full audit logging that records who approved, who used, and what was accessed.
• Secrets rotation so the access path does not remain valid after the task completes.

This is especially important for systems that hold production credentials, API keys, or infrastructure tokens, because shared access creates both lateral movement risk and audit ambiguity. The practical lesson is the same one reinforced by NHIMG research on secret sprawl: permanent credentials become the default if the emergency path is too slow, which turns “temporary convenience” into standing privilege. These controls tend to break down when responders must coordinate across multiple consoles and cloud tenants because approval latency and secret distribution become harder to automate.

Common Variations and Edge Cases

Tighter on-call access often increases operational overhead, so organisations have to balance speed against control rather than pretending both come free. That tradeoff is why break-glass procedures still exist, but current guidance treats them as exceptional, monitored, and rapidly revoked rather than as the normal operating model.

Some environments still use shared credentials for legacy systems, vendor portals, or tools that cannot issue per-user access. In those cases, best practice is evolving, and there is no universal standard for this yet, but the minimum expectation is compensating controls: strong monitoring, rapid rotation, session recording where possible, and explicit post-use review. The Top 10 NHI Issues and the Guide to the Secret Sprawl Challenge both reflect the same operational reality, which is that access sprawl usually grows fastest where urgency is highest.

For teams managing hybrid estates, the hard case is not policy design but consistency. A manual approval process that works for one platform may collapse across multiple clouds, third-party SaaS tools, or legacy infrastructure because responders need too many exceptions. That is where ephemeral access, ownership-based policy, and individual accountability matter most. In environments with legacy appliances that cannot support short-lived credentials, manual approval should be treated as a temporary bridge, not the target state.

Related resources from NHI Mgmt Group

• What breaks when database access is managed with shared credentials?
• What breaks when access is managed through too many manual steps?
• What breaks when SSH access still relies on shared credentials?
• What breaks when a former employee still has access to shared cloud root credentials?