What should organisations do when an app cannot support identity automation?

Why This Matters for Security Teams

When an application cannot support identity automation, the risk is not just extra admin work. It is the loss of consistent control over provisioning, deprovisioning, and periodic review, which is where service accounts, API keys, and other secrets most often become durable attack paths. NHI Mgmt Group’s Ultimate Guide to NHIs shows why this matters: only 20% of organisations have formal processes for offboarding and revoking API keys, and 71% of NHIs are not rotated on time. That gap becomes more dangerous when the app cannot plug into IAM tooling, ticketing, or vault automation. Current guidance from NIST Cybersecurity Framework 2.0 still points teams toward governance, review, and accountable access control even where the technology stack is uneven. The practical issue is that manual handling often survives as an informal exception long after the original business need has changed. In practice, many security teams encounter stale access only after an audit finding, a leaked secret, or a service outage has already exposed the gap.

How It Works in Practice

The right response is to replace automation with a documented compensating control, not with one-off approval habits. That control should name the application owner, define who can request access, specify how credentials are issued, and set the exact evidence needed for review and removal. For NHI governance, this usually means a repeatable workflow that covers:

• named business and technical ownership for the app and its secrets
• manual provisioning steps with ticket references and approver identity
• deprovisioning triggers tied to role changes, project closure, or inactivity
• recurring attestations that verify the app still needs each identity or secret
• vaulting or escrow of secrets where direct automation is impossible

The standard should be least privilege, short-lived access where feasible, and documented exceptions where not. NHI Mgmt Group’s Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the same lesson: unmanaged exceptions become persistent exposure points, especially when secrets are stored outside a controlled lifecycle. Where possible, pair the exception with policy-based review under NIST Cybersecurity Framework 2.0 so the control is measured, not merely described. These controls tend to break down in legacy, vendor-hosted, or mainframe-connected environments because identity state cannot be queried reliably and revocation evidence is hard to automate.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations have to balance risk reduction against business continuity and support burden. Some teams can use partial automation, such as ticket-driven approval plus vault-managed secret rotation, while others must rely on scheduled reviews because the application exposes no usable API or lifecycle hooks. Best practice is evolving, and there is no universal standard for this yet, but the direction is consistent: every exception should be time-bounded, owned, and reviewable. If the application is critical, one common variation is to reduce the blast radius rather than force full automation, for example by isolating the app, narrowing the scope of the secret, or placing the account behind PAM and strict RBAC. NHI Mgmt Group’s JetBrains GitHub plugin token exposure is a good reminder that even well-known tooling can leak secrets when lifecycle controls are weak. For organisations aligning to broader risk programs, the governance expectation also fits the spirit of NIST Cybersecurity Framework 2.0: identify the exception, protect it with compensating controls, and verify it on a recurring basis.

Related resources from NHI Mgmt Group

• How do organisations know if patient access identity controls are working?
• How should organisations decide whether their multi-cloud identity model is working?
• How should security teams govern app identity modernization across multi-cloud environments?
• How can organisations govern sensitive agent actions without blocking automation?