Pave And Repave

A restoration method that rebuilds a compromised system from a clean operating system image and then layers trusted data back on top. It is especially useful when malware may have embedded itself below the application layer or inside the original OS state.

Expanded Definition

Pave and repave is a recovery pattern used when a compromise is too deep to trust the original system state. The system is rebuilt from a known-clean operating system image, then only validated data, binaries, and configuration are restored. In NHI and agentic AI environments, that often means reimaging a host that ran service accounts, API workers, orchestration agents, or credential brokers after malware, rootkit behavior, or persistence mechanisms are suspected.

The important distinction is that this is not the same as standard patching or rollback. Patching assumes the base platform remains trustworthy; pave and repave assumes it may not. That makes the approach especially relevant to trust boundaries involving secrets, tokens, certificates, and automation identities. It also aligns with the response logic described in the NIST Cybersecurity Framework 2.0, where recovery depends on restoring integrity, not just service availability. Definitions vary across vendors when the term is used for containers, virtual machines, or full endpoints, but the core principle is unchanged: destroy the contaminated state and reconstruct from a trusted baseline.

The most common misapplication is treating a cleanup script or partial reset as a true repave when persistent malware or stolen credentials can still survive in the original trust chain.

Examples and Use Cases

Implementing pave and repave rigorously often introduces downtime and rebuild complexity, requiring organisations to weigh faster service restoration against the cost of revalidating every dependency.

• A build server used to mint signed artifacts is reimaged after investigators confirm persistence in the OS layer, then only trusted pipelines and new credentials are restored.
• An AI agent host that stored long-lived API keys in local config is wiped and rebuilt after exfiltration, with fresh secrets issued from a controlled vault.
• A Kubernetes node is repaved after suspicious daemon behavior, while pod definitions, images, and service account bindings are redeployed from signed sources.
• A privileged automation VM is rebuilt after lateral movement is detected, with access to the new environment gated through PAM and tightly scoped RBAC.
• A compromised secrets broker is repaved to eliminate hidden persistence before rotation of certificates and token lifetimes resumes.

The NHI Management Group notes that Ultimate Guide to NHIs reports 79% of organisations have experienced secrets leaks, which helps explain why repave decisions often follow credential exposure rather than visible service failure alone. In zero trust-oriented recovery, rebuilds are paired with fresh identity issuance, not just restored binaries.

Why It Matters in NHI Security

Pave and repave matters because NHI compromise is often about persistence, not just damage. A stolen service account, embedded token, or compromised agent host can continue to operate even after the obvious malware is removed. If the base system is not rebuilt, the attacker may retain hidden footholds, cached secrets, scheduled tasks, startup hooks, or tampered trust material. That is why this recovery method is often the safest option when automation identities or privileged workloads are involved.

It is also where governance and operations meet. NHI environments tend to move fast, and the blast radius is amplified when secrets are stored outside managed vaults or when service accounts are not fully inventoried. The Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts, which means recovery teams often learn the true scope of compromise only during remediation. A second NHIMG signal is equally stark: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Organisations typically encounter the need for pave and repave only after a persistence event, at which point it becomes operationally unavoidable to address.