Dependency graph severability

Expanded Definition

dependency graph severability describes whether a source credential platform can be removed after migration without breaking any downstream business process, automation, or integration. In NHI security, the term is more precise than simple decommissioning because it requires proof that every consumer path has already been re-pointed, validated, and monitored on the target platform. Definitions vary across vendors, but the operational meaning is consistent: if a graph still depends on the old issuer, vault, or secrets store, the migration is not complete.

This concept aligns with the control intent behind the NIST Cybersecurity Framework 2.0, especially the need to manage asset and dependency risk across changing systems. It also overlaps with broader NHI lifecycle governance described in NHI Mgmt Group guidance on the ultimate guide to non-human identities. Severability is not just a platform question, because consumers may include CI/CD jobs, service accounts, workloads, agents, and third-party automations. The most common misapplication is declaring severability based on successful secret replication alone, which occurs when teams validate storage migration but do not confirm that every consumer path has stopped calling the source platform.

Examples and Use Cases

Implementing dependency graph severability rigorously often introduces migration slowdown, requiring organisations to weigh operational safety against the cost of parallel running and validation effort.

• A secrets vault is migrated, but a legacy deployment job still fetches API keys from the old path, so the source vault cannot be retired.
• A service account registry is replaced, yet a batch pipeline continues to depend on the old token issuer until its refresh logic is updated and tested.
• An agentic workflow is moved to a new credentials platform, but its tool-calling permissions still reference the original NHI store during failover testing.
• A platform team uses dependency mapping to prove that all consumer paths have been remediated before disabling the old credential broker, following NHI lifecycle guidance from NHI Mgmt Group.
• A migration is blocked because one Terraform module still hardcodes a source secret lookup, which is later replaced with a validated target lookup consistent with NIST Cybersecurity Framework 2.0 practices.

Why It Matters in NHI Security

Dependency graph severability is what turns NHI migration from a hopeful cutover into a defensible operational decision. Without it, organisations often believe they have reduced risk while the source platform remains a hidden dependency, still able to issue credentials, serve stale tokens, or anchor orphaned automation. That creates exposure around offboarding, rotation, and privilege reduction, especially where workloads are numerous and opaque. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which helps explain why severability is so often assumed rather than proven, and why it belongs in the same governance conversation as visibility and offboarding in NHI risk management. It also supports the dependency awareness expected in the NIST Cybersecurity Framework 2.0. Organisations typically encounter this issue only after the old platform is disabled and a critical workflow fails, at which point severability becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Dependency graph
• Agent Dependency Graph
• Historical Dependency Graph
• When does a dependency compromise become an identity incident?