Secret rotation is the control gap in NHI compliance and breach recovery

At a glance

What this is: This is a secret rotation analysis that argues rotation must be operationalised across breaches, compliance, offboarding, and continuity, because vaults and monitoring alone do not close exposure paths.

Why it matters: It matters because IAM, PAM, and NHI programmes all depend on knowing when credentials outlive the identity, the workflow, or the organisational change that created them.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility.

👉 Read Oasis Security's analysis of secret rotation, compliance, and breach recovery

Context

Secret rotation is the practice of replacing credentials, tokens, keys, and certificates before they become an exposure point. In NHI programmes, rotation is not just a hygiene task. It is the control that limits how long a secret can be used if it is copied, shared, or discovered outside intended channels.

The problem is that many organisations still rely on offboarding, vaulting, or detection as if each were sufficient on its own. This article argues that those controls reduce risk but do not remove the need for continuous rotation, especially when service access, cloud reachability, and organisational change all affect non-human identity security.

For teams managing NHI, PAM, and lifecycle governance together, the point is simple: a secret is only safe for as long as its validity window is genuinely controlled. That is why secret rotation sits at the intersection of access reviews, breach response, and operational resilience, not just security tooling.

Key questions

Q: How should security teams handle secret rotation after a breach or exposure?

A: Security teams should treat breach response as a rotation event, not just an investigation. The exposed credential must be replaced, related service dependencies must be checked, and any downstream systems using cached or copied values must be updated. If the same secret can still authenticate anywhere, the breach remains active in practice.

Q: Why do secrets need rotation even when they are stored in a vault?

A: Vault storage reduces casual exposure, but it does not guarantee that every application is retrieving secrets from the vault at runtime. Secrets may still be copied into configs, logs, tickets, or code. Rotation is what invalidates the copied value, which is why vaulting and rotation are complementary controls, not substitutes.

Q: What breaks when offboarding does not include secret revocation?

A: The former identity may be removed in IAM while the credential itself remains usable by the ex-employee or by any system that still knows it. That creates a mismatch between lifecycle state and authentication state. The result is lingering access that survives the person-to-system relationship that created it.

Q: Who is accountable for secret rotation across IAM, PAM, and NHI programmes?

A: Accountability usually sits with the system owner, the identity team, and the application owner together, because each controls part of the secret lifecycle. IAM defines the lifecycle event, PAM governs privileged secrets, and NHI operations handle the runtime credential. If no owner can revoke it quickly, the control is incomplete.

Technical breakdown

Why secret rotation limits exposure windows

A secret is a reusable credential that authenticates a workload, service, or user-to-system path. Rotation reduces the time during which a copied or leaked credential remains usable, which matters because secrets are often spread across chat tools, tickets, code, and runtime environments. The technical goal is not secrecy alone, but short-lived usability. If a secret can be reused after discovery, every downstream dependency inherits the same exposure. Rotation therefore works as a blast-radius control, not a guarantee of prevention.

Practical implication: map where each secret is valid, how often it changes, and what downstream systems break when it is replaced.

Why vaulting does not eliminate rotation needs

Vaults store secrets centrally and can improve visibility, but they do not ensure that every application retrieves secrets from the vault at runtime. Some systems still cache credentials, embed them in configuration, or reuse them outside the vault path. That creates a gap between policy and actual use. If a secret is exposed through phishing, logs, or a shared workspace, vault storage does nothing to invalidate the copy already in circulation. Rotation remains necessary because containment depends on replacing the credential, not only storing it well.

Practical implication: verify which applications are truly vault-backed versus merely vault-aware before you treat central storage as control coverage.

How lifecycle events create secret drift

Joiner, mover, and leaver events alter who or what should still be able to use a credential. A former employee account may be closed in IGA while a related non-human credential remains active, especially where cloud services are directly reachable from outside the corporate perimeter. Secret drift happens when ownership, usage, and revocation fall out of sync. That is why lifecycle governance must extend beyond human account state to the secrets and service identities attached to the role, app, or vendor relationship.

Practical implication: tie every offboarding and role change to explicit secret inventory checks and revocation actions.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret rotation is a containment control, not a cleanliness exercise. The article correctly frames rotation as the mechanism that shortens the life of an exposed credential after breach, audit failure, or organisational change. In NHI governance terms, the issue is not whether a secret exists, but how long it remains valid once exposed. That distinction matters because exposure often happens outside the vault, and the practical security question becomes how quickly the organisation can make the old credential unusable.

Offboarding controls fail when they stop at the human account. The article’s strongest point is that closing an employee identity in IGA does not automatically revoke the non-human credentials that employee knew or managed. That is a lifecycle governance gap, not a visibility problem. The implication for practitioners is that account termination and secret termination are different control actions, even when they are triggered by the same leaver event.

Secret drift: the credential outlives the business process that justified it. This is the named concept the article exposes across vaulting, monitoring, and organisational change. A secret becomes drifted when it continues to authenticate after the app owner, employee, or workflow has changed. That failure mode is what turns routine operational slippage into persistent NHI exposure, and teams need to treat it as a governance state, not an exception.

Monitoring cannot substitute for revocation authority. The article is right that CSPM and ITDR can detect anomalies, but detection does not remove standing access. NHI programmes that depend on alerts to drive manual cleanup are still accepting an exposure window that remains open until someone acts. The governance lesson is that discovery and rotation are paired controls, and the latter is the one that actually ends the risk.

Automated rotation is the difference between repeatable governance and ad hoc rescue. The scream test model described here is not scalable governance because it proves use by breaking things. In mature identity programmes, secret rotation has to be programmatic, observable, and tied to lifecycle events so that the control works even when no one is watching. Practitioners should treat automation as the delivery mechanism for policy, not as an optional enhancement.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, according to Entro Security, which increases the chance that rotation must clean up more than one live copy.
• Follow the NHI Lifecycle Management Guide for the lifecycle controls that should trigger revocation, rotation, and ownership reassignment.

What this signals

Secret drift: the biggest operational risk is not a missing vault but a stale credential that still works after the business event that should have retired it. Teams should expect rotation demand to rise whenever ownership changes, because lifecycle churn is now the primary driver of secret exposure.

With 62% of all secrets duplicated and stored in multiple locations, per The 2025 State of NHIs and Secrets in Cybersecurity, programme leaders need to assume that one revocation action may not be enough. Discovery, correlation, and enforced replacement have to move together if rotation is going to reduce real attack surface.

Organisations that want predictable control should anchor secret handling to the Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10. The signal for practitioners is clear: secret governance is becoming an operational discipline, not a periodic cleanup task.

For practitioners

• Inventory every live secret and its true dependency path Build a complete inventory of secrets, tokens, and certificates, then map which applications, integrations, and humans can still use them. Prioritise credentials that appear in tickets, chat tools, or code commits because those are the easiest to copy and reuse. Link the inventory to the NHI Lifecycle Management Guide for operational structure.
• Trigger rotation on breach, offboarding, and role change events Do not wait for periodic clean-up cycles. Rotate or revoke secrets when a breach occurs, when an employee leaves, and when a role change alters access need. Treat those events as mandatory revocation points, not discretionary reviews. Align the process with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• Separate vault storage from actual runtime enforcement Confirm that applications retrieve secrets from the vault at runtime rather than caching or embedding them locally. Where runtime enforcement is missing, rotation should be paired with application fixes so the old value cannot keep authenticating. Use the Guide to the Secret Sprawl Challenge to anchor remediation work.
• Replace scream-test rotation with automated revocation workflows Use automation to disable, replace, and validate secrets without waiting for business users to complain that something broke. Add logging that records what was rotated, why it was rotated, and which systems were updated. This turns rotation into a repeatable control rather than an emergency exercise.

Key takeaways

• Secret rotation matters because exposed credentials remain useful long after the event that created them.
• The scale problem is lifecycle failure, not just vault failure, because tokens and secrets often survive offboarding and duplicate across systems.
• Practitioners should tie rotation to breach response, leaver events, and runtime enforcement, or the control will remain mostly theoretical.

Key terms

• Secret Rotation: Secret rotation is the practice of replacing credentials, tokens, keys, or certificates before their current value should be trusted again. In identity programmes, it limits how long an exposed secret can be used and is most effective when tied to breach response, lifecycle events, and runtime enforcement.
• Secret Drift: Secret drift is the condition where a credential continues to exist and authenticate after the business process, owner, or system relationship that justified it has changed. It is a governance failure because ownership, usage, and revocation have moved out of sync across the identity lifecycle.
• Non-Human Identity: A non-human identity is a machine or service credential used by software rather than a person. It can be a token, certificate, API key, or service account, and it needs lifecycle governance because it often persists independently of human offboarding or role changes.

Deepen your knowledge

Secret rotation, lifecycle-driven revocation, and non-human credential governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme around leaks, offboarding, or vault sprawl, it is worth exploring.

This post draws on content published by Oasis Security: The Importance of Secret Rotation in Ensuring Security and Compliance. Read the original.