A replacement update happens when a configuration change cannot be applied in place and the existing resource must be deleted and recreated. This matters because the behaviour can look like a routine modification while actually causing service interruption, dependency breakage, or unexpected loss of stateful resources.
Expanded Definition
A replacement update is a change operation that cannot safely modify a resource in place, so the platform removes the existing object and creates a new one. In NHI and IAM environments, that distinction matters because the visible outcome may resemble an ordinary configuration change while the actual effect is a reset of identity state, trust bindings, network attachments, or secret references.
Definitions vary across vendors and infrastructure platforms, but the operational pattern is consistent: if the resource has immutable fields, incompatible schema changes, or dependencies that cannot be rewritten live, the update becomes destructive in practice. That is why a replacement update must be treated as a lifecycle event, not just a deployment detail. In access and identity systems, this can affect service accounts, certificates, workload identities, policy objects, and agent permissions. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to manage configuration changes under controlled processes, especially where integrity and availability are sensitive.
The most common misapplication is assuming a replacement update is a harmless patch, which occurs when operators fail to check whether the target resource carries state, persistent credentials, or downstream dependencies.
Examples and Use Cases
Implementing replacement updates rigorously often introduces downtime and coordination overhead, requiring organisations to weigh deployment simplicity against the risk of interrupting live identity-dependent services.
- A workload identity in a cluster is replaced because its immutable issuer or audience settings cannot be edited in place, forcing token consumers to rebind.
- A certificate-backed service account is recreated during a rotation workflow, and dependent applications must update trust stores before traffic resumes.
- An infrastructure-as-code plan replaces an access policy object after a schema change, requiring validation that all NHI permissions are restored correctly.
- A CI/CD-managed secrets reference is recreated during a vault migration, and the pipeline must be checked for broken token paths or stale environment variables.
- A cloud resource with an attached role is destroyed and rebuilt, exposing whether entitlement recovery is automated or dependent on manual reauthorization.
For broader NHI lifecycle context, the Ultimate Guide to NHIs explains how identity visibility, rotation, and offboarding become fragile when changes are not planned as controlled replacements. In platform engineering terms, replacement behaviour is often discussed alongside immutable infrastructure and rollout safety, while identity teams must also consider how the change affects trust propagation and service continuity.
Why It Matters in NHI Security
Replacement updates matter because NHI assets often carry privileges, secret references, and machine-to-machine trust that can break silently when a resource is recreated. If the update is not governed, a new object may inherit a different identifier, lose its previous bindings, or reconnect with broader access than intended. That can create service disruption, unexpected privilege drift, or orphaned credentials that remain valid after the original resource is gone.
This risk is not theoretical. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, as documented in the Ultimate Guide to NHIs. Those conditions make replacement updates especially dangerous when teams assume the recreated object is functionally identical to the original. The operational concern is not only uptime, but also whether the new identity instance has the same constrained scope, secret state, and audit trail as the one it replaced.
Organisations typically encounter the real impact only after a failed rollout or a broken dependency chain, at which point replacement update handling becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Replacement updates can destroy and recreate NHIs, affecting lifecycle and access continuity. |
| NIST CSF 2.0 | PR.DS-1 | Destructive updates can disrupt data state and service continuity if not controlled. |
| NIST Zero Trust (SP 800-207) | SC | Recreated resources must be re-established inside zero trust trust boundaries. |
Treat recreated identities as new assets and revalidate permissions, bindings, and secret references before use.
