Notifications
Clear all
Topic starter
04/07/2026 10:02 pm
TL;DR: PAM migrations often stall not on onboarding, but on proving the legacy vault can be turned off, because the dependency graph lives in consuming systems rather than the vault itself, according to Hydden. The real control problem is observability, not credential export: without estate-wide evidence of last reference, the old platform keeps running.
NHIMG editorial — based on content published by Hydden: PAM migrations are far more complex than credential platform moves
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a PAM migration is treated as an onboarding project?
A: The migration appears complete while the legacy vault still has active consumers.
Q: Why do PAM migrations stall at decommission even after onboarding reaches 100%?
A: Because onboarding measures only what has been copied into the target platform, not whether any system still depends on the source.
Q: How do security teams know a legacy vault can actually be shut off?
A: They need observed proof that no active system still authenticates through the old platform over the relevant operating cycle.
Practitioner guidance
- Build a dependency graph before cutover Inventory every privileged identity, secret, and consumer relationship across applications, scripts, scheduled jobs, and appliances before you repoint anything.
- Observe authentication across extended cycles Watch which identity authenticates to which vault, from which source system, over a window long enough to capture quarterly, annual, and disaster-recovery execution paths.
- Repoint consumers before removing source access Validate each consumer against the target platform, including client certificates, application registrations, and allow-list entries, before you sever the old endpoint.
What's in the full article
Hydden's full article covers the operational detail this post intentionally leaves for the source:
- How to enumerate every consumer path that still calls the legacy vault, including scripts, batch schedulers, and appliance integrations
- How to validate last-reference evidence over long observation windows before decommission approval
- How to handle session brokers, client certificates, and re-vaulting during target cutover
- How to sequence rotations so the source platform can be removed without breaking dependent systems
👉 Read Hydden's analysis of why PAM migrations stall at decommission →
PAM migration decommissioning gaps: what IAM teams miss?
Explore further
04/07/2026 10:09 pm
Decommissioning failure is the real PAM migration failure mode: the project is not complete when credentials have been copied into a target vault. It is complete only when the source can be shut off without any consumer still depending on it. That means the migration problem is observability of dependency, not asset movement, and the old platform survives whenever that proof is missing. Practitioners should treat source removal as the primary control objective.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned".
A question worth separating out:
Q: Who is accountable when a PAM migration causes authentication failures?
A: Accountability sits with the identity, PAM, and application owners who approved decommission without verifying dependencies. In regulated environments, the evidence trail also matters because session records, access history, and attestation continuity must survive the migration. The control failure is usually procedural, not just technical.
👉 Read our full editorial: PAM migration failures are really decommissioning failures
