Why do change workflows matter for IAM and NHI programmes?

Because many access changes happen during the same business events that trigger IT change requests, such as onboarding, role moves, application rollouts, and offboarding. If those events are not linked to provisioning and revocation, both human and non-human identities can keep stale access long after the change is finished.

Why Change Workflows Matter for IAM and NHI Programmes

Change workflows matter because identity state rarely changes in isolation. A role move, onboarding event, application release, contractor exit, or service migration often changes who or what should have access at the same time. When IAM and NHI provisioning are not tied to those business events, access drifts. That drift leaves stale human permissions, orphaned service accounts, and long-lived secrets in place after the operational need has ended.

For IAM teams, the control objective is not just approval. It is making sure access creation, modification, and revocation are triggered by the same workflow that changes the business context. For NHI programmes, this is even more important because machine access often outlives the application change that created it. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often change management and identity lifecycle are disconnected.

The practical issue is that identity risk compounds during routine change, not only during incidents. The NIST Cybersecurity Framework 2.0 treats governance and access control as operational disciplines, not one-time events. In practice, many security teams encounter stale access only after a migration, go-live, or offboarding event has already completed.

How Change Workflows Connect Access, Revocation, and Auditability

Effective change workflows create a shared control point for identity, infrastructure, and application teams. The key is to treat access changes as part of the change record, not as a separate afterthought. That means the workflow should identify the affected person, workload, service account, secret, API key, certificate, or privileged role; define the requested state; route approval where needed; and verify that provisioning or revocation actually occurred.

For human identities, this supports joiner, mover, and leaver actions. For NHIs, it supports application deployments, environment changes, key rotation, certificate replacement, and decommissioning. Where possible, the workflow should invoke automated controls such as JIT provisioning, secret rotation, and time-bound access expiry. It should also record the evidence needed for audit, including who approved the change, what identity was affected, when access was granted or removed, and whether downstream systems updated correctly.

Best practice is evolving toward policy-driven workflows, especially where service accounts and machine identities are involved. NHI governance guidance in the Top 10 NHI Issues emphasises visibility, rotation, and offboarding because those controls fail when change tickets and identity actions are managed in separate systems. External implementation guidance from CISA Identity and Access Management reinforces that lifecycle management should be continuous, not periodic.

• Link change tickets to access requests, secret rotation, and revocation tasks.
• Use automated checks to confirm the target identity state matches the approved change.
• Require evidence that retired accounts, tokens, and certificates are disabled or expired.
• Track exceptions for emergency changes and review them after the fact.

These controls tend to break down in hybrid environments where application teams, cloud teams, and IAM teams operate separate ticketing and deployment paths because identity changes then slip through without a single owner.

Common Variations and Edge Cases

Tighter change control often increases delivery overhead, requiring organisations to balance speed against assurance. That tradeoff is real in fast-moving engineering environments, especially where continuous deployment, ephemeral infrastructure, or delegated admin models are in use. The goal is not to slow every release, but to make identity changes deterministic and traceable.

There is no universal standard for how granular the workflow must be. Some organisations embed identity steps directly into CI/CD pipelines; others require explicit approval gates for privileged changes or production secrets. Current guidance suggests that the more sensitive the access, the more the workflow should enforce separation of duties, short-lived credentials, and post-change verification. For lower-risk access, lighter-weight automation may be sufficient if it still revokes stale permissions quickly.

Edge cases matter most when changes affect shared services, third-party integrations, or break-glass access. A contractor leaving a project may still have access through a shared toolchain token. A rotated certificate may leave old workloads functioning until the next restart. A moved employee may retain entitlements in a downstream system not covered by the original ticket. NHIMG’s 52 NHI Breaches Analysis and the Cisco DevHub NHI breach both underscore how stale machine access can persist well beyond the intended change window.

For this reason, change workflows should always include a cleanup path, not just an approval path. If a workflow cannot prove that access was removed, rotated, or expired, the change is not really complete.

Related resources from NHI Mgmt Group

• When do adaptive access controls matter most for IAM and NHI programmes?
• Why do cryptographic changes matter to IAM and NHI programmes?
• Why does cryptographic agility matter for IAM and NHI programmes?
• Why does support speed matter in IAM and NHI programmes?