Both are required, but revocation has to happen as part of containment, not after the rebuild is finished. Rebuilding removes the attacker’s local foothold, while revoking affected SVIDs closes the access paths that the issued identities still hold.
Why the rebuild and revocation sequence matters after compromise
A rebuild only removes what is on the node. If issued identities, certificates, or tokens still work, the attacker may keep using valid access paths even after the system is reimaged. Containment has to address both the host and the trust material that authenticated it, otherwise the compromise can survive the rebuild.
That is why security teams should treat revocation as part of containment, not as a cleanup task after restoration. If you rebuild first and delay revocation, you risk restoring a trusted node into an environment where the old access path is still accepted.
What revocation actually closes in an identity compromise
In practice, revocation cuts off the access the attacker still has through the compromised identity, while rebuild resets the local system state. For node-based infrastructure, that often means invalidating SVIDs, certificates, tokens, or other machine credentials that can still authenticate after the host is rebuilt.
This distinction matters because compromise is often both a system problem and an access problem. The node can be clean, but if the identity it used remains valid, the trust relationship remains exploitable until the credential or issued identity is withdrawn, expired, or replaced.
For background on how these failure modes show up across non-human identities, see Ultimate Guide to NHIs — Key Challenges and Risks and the broader NHI lifecycle management guidance.
How to decide what to do first in an incident
The practical rule is simple: isolate the node, revoke the compromised identities, then rebuild and restore from known-good state. If the compromise could have involved exposed secrets, shared credentials, or a trusted workload identity, revocation needs to happen immediately enough to stop ongoing use, not after imaging work is complete.
- If the identity can still authenticate, revoke it before or during rebuild.
- If the node is suspected of broader tampering, rebuild from trusted media and verify persistence is removed.
- If there are dependent services using the same credential material, rotate or replace those credentials as part of the containment plan.
Identity-focused response is easier to manage when teams have a clear lifecycle model and ownership for issued identities. NHIMG’s Identity Security Programme Guide and NHI Lifecycle Management Guide both reinforce that revocation, rotation, and offboarding are operational controls, not optional follow-up tasks.
Risk and Threat Considerations
When teams rebuild before revoking identities, the main risk is residual access. The attacker may lose the original node, but still retain a valid credential path, which can support re-entry, lateral movement, or continued abuse of downstream services.
Failure mechanism: The rebuild clears local compromise, but the issued identity remains trusted by other systems until it is revoked or replaced. That creates a gap where remediation has removed the device foothold without ending the compromise.
Impact: The incident can persist after remediation, making recovery appear successful while the attacker still holds authenticated access. In distributed environments, that can also create repeated reinfection, failed assurance, and delayed containment across dependent services.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Compromised node identities must be revoked to end access. |
| NHI-04 — Insecure Authentication | Issued SVIDs or tokens can keep authenticating after rebuild. | |
| NHI-07 — Long-Lived Secrets | Persistent credentials can outlive the rebuilt host and preserve attacker access. | |
| Recommendation — Revoke issued NHI access immediately when the node is compromised. Invalidate compromised authentication material before trusting the rebuilt node. Shorten or eliminate long-lived credentials used by the compromised node. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle controls govern revocation and replacement of compromised credentials. |
| IA-9 — Service Identification and Authentication | Node-to-node trust depends on service credentials that must be withdrawn after compromise. | |
| AC-6 — Least Privilege | Excess authority increases the damage if a node identity remains valid. | |
| Recommendation — Revoke and replace compromised authenticators as part of containment. Invalidate service authenticators before restoring workload trust. Reduce node privileges so surviving credentials cannot reach unnecessary resources. | ||
Practitioner Guidance
What to prioritise: Treat revocation as a containment action. If the compromised node had any live identity material, stop trusting that material first or in parallel with rebuild work.
What to verify: Confirm that the affected SVIDs, certificates, tokens, or API credentials are no longer accepted anywhere they could authenticate, and check for shared reuse across workloads or environments.
Common mistake: Teams often assume that a fresh node equals a clean incident. The better test is whether the attacker’s authentication path has been eliminated, not whether the disk has been reimaged.
Practitioner takeaway: Rebuild removes the compromised host, but revocation removes the attacker’s remaining authority, so containment is incomplete until both are handled together.