TL;DR: The practical shift is from audit paperwork to automated evidence, inventory, and policy drift control, according to Anchore research. Anchore argues that point-in-time compliance no longer fits production Kubernetes, because the EU Cyber Resilience Act and continuous runtime change require teams to prove what is running now, not reconstruct it later.
At a glance
What this is: This is a CompOps analysis of why continuous audit readiness is becoming necessary for Kubernetes environments under the EU Cyber Resilience Act.
Why it matters: It matters because IAM, NHI, and platform teams need runtime evidence, not just build-time controls, when workloads, identities, and entitlements change continuously in production.
Context
Traditional compliance models assume systems stay stable long enough for periodic review, but Kubernetes breaks that assumption because workloads, images, and runtime state change continuously. In that environment, proving control effectiveness depends on live inventory and evidence capture rather than retrospective reconstruction.
The article frames Compliance Operations, or CompOps, as the response to this gap: embedding compliance requirements into the system lifecycle as version-controlled code and treating audit evidence as an operational output, not a manual afterthought. That matters wherever identity and access decisions are tied to ephemeral infrastructure and short-lived deployment states.
Key questions
Q: How should security teams prove what is running in Kubernetes during an audit?
A: They should rely on live inventory, runtime evidence, and timestamped state capture rather than build records alone. In Kubernetes, the audit object is the running workload, so the control objective is to show exactly which pods, images, and configurations existed at a specific time. If that evidence cannot be produced quickly, the environment is not continuously audit-ready.
Q: What breaks when compliance is only checked at release time?
A: The organisation loses visibility into drift, redeployment, and post-deployment changes that alter the real risk profile. A workload can pass build-time checks and still become non-compliant in production. That creates a gap between approval and reality, which is exactly where audit findings and exposure accumulate.
Q: Why do ephemeral platforms need continuous evidence generation?
A: Because ephemeral systems change faster than periodic reviews can capture. Continuous evidence generation ensures that inventory, policy state, and runtime identity are captured while the system is live, which is the only way to prove control effectiveness when workloads are short-lived and frequently replaced.
Q: What is the difference between build-time compliance and runtime compliance?
A: Build-time compliance checks whether a workload met policy before deployment, while runtime compliance checks whether the live system still matches that policy after deployment. In Kubernetes, both matter, but runtime compliance is the stronger control when images, pods, and permissions can drift continuously.
Technical breakdown
Why point-in-time compliance fails in Kubernetes
Kubernetes is an ephemeral control plane where pods can appear, disappear, and mutate faster than traditional audit cycles can track them. That creates a gap between what was approved at build time and what is actually running at the moment of review. In practice, versioned manifests and pipeline approvals do not prove runtime state, especially when images are redeployed, drift is introduced, or a vulnerable container remains active long after the build passed. CompOps addresses that gap by treating evidence as continuous telemetry rather than a periodic report.
Practical implication: Treat runtime state as the audit object, not the deployment record.
How continuous inventory closes the runtime blind spot
A continuous inventory model polls the Kubernetes API to maintain a live, digest-accurate view of running pods and images. That matters because image tags alone are not reliable proof of what is executing, while digests and runtime observations can be tied to a specific state at a specific time. This turns impact analysis from a broad guess into a precise mapping of vulnerable workloads, and it gives compliance teams a defensible evidence trail for what existed during a given window.
Practical implication: Base audit evidence on verified runtime inventory, not static deployment metadata.
Why policy drift becomes a compliance problem
Policy drift occurs when a workload remains in production after its risk posture has changed, such as when a container was compliant at deployment but later falls outside accepted thresholds. In Kubernetes, that drift can arise without a new release, simply because the environment is dynamic and the inventory changes underneath the control assumptions. When teams cannot detect drift quickly, compliance stops being an evidence problem and becomes an exposure problem, because the organisation can no longer show which workloads were compliant at the time they mattered.
Practical implication: Automate drift detection so runtime exceptions are visible before they become audit findings.
NHI Mgmt Group analysis
Point-in-time compliance is no longer a defensible operating model for ephemeral infrastructure. Kubernetes changes too quickly for annual or even quarterly evidence gathering to provide reliable assurance. The underlying issue is not just audit inefficiency, but the collapse of the old assumption that system state remains stable long enough to review after the fact. Practitioners need to treat compliance as a live control surface, not a retrospective paperwork exercise.
Runtime evidence is becoming a governance requirement, not a technical convenience. Once production state drives regulatory exposure, the question shifts from whether teams have a policy to whether they can prove enforcement at the moment of execution. That is why live inventory, timestamped state capture, and digest-level visibility matter more than static attestations. The operational conclusion is that evidence generation must be built into the platform, not assembled during audit season.
Runtime evidence gap: audit failure in Kubernetes now comes from the inability to reconstruct what was actually running, not from the absence of a policy document. CompOps is useful because it narrows that gap by making compliance artifacts emerge from the same lifecycle that creates the workload. For identity-heavy environments, that same logic applies to service accounts, tokens, and other non-human identities that change with the runtime fabric. Teams should govern the state that exists, not the state they hoped existed.
The CRA is pushing security teams toward continuous assurance models. The article shows how regulatory pressure and ephemeral infrastructure are converging on the same requirement: machine-readable evidence tied to actual runtime conditions. That shift matters beyond Kubernetes because the broader control problem is the same in modern identity and cloud estates. Practitioners should align evidence, inventory, and enforcement so governance keeps pace with deployment speed.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Runtime evidence has become the new control boundary for ephemeral infrastructure. When workloads can be replaced, mutated, or redeployed in minutes, governance cannot depend on static approvals or delayed reviews. Security and compliance teams need continuous visibility into what is actually executing so that evidence, exception handling, and accountability stay aligned with production reality.
CompOps reframes compliance as a system property rather than a document outcome. That shift matters for identity-rich platforms because runtime state now includes workload identities, access paths, and policy enforcement points that change with every deployment. Teams that still separate audit evidence from operational telemetry will keep finding the same gap: they can describe what should be running, but not prove what is running now.
For practitioners
- Automate runtime inventory capture Continuously poll cluster state and retain digest-accurate records of running pods and images so audit evidence reflects actual execution, not deployment intent.
- Tie policy checks to live workload state Use runtime policy evaluation to flag workloads that drift beyond accepted risk thresholds even when their build-time approval was valid.
- Produce timestamped evidence on demand Generate audit reports from live operational data so teams can answer what was running on a given date without manual reconstruction. Read the Ultimate Guide to NHIs: Regulatory and Audit Perspectives.
- Embed compliance into the delivery lifecycle Treat compliance requirements as version-controlled configuration and lifecycle logic rather than a separate annual review process.
Key takeaways
- Kubernetes compliance fails when teams rely on periodic review instead of live proof of runtime state.
- Continuous inventory and timestamped evidence close the gap between approved builds and actual production workloads.
- CompOps matters because audit readiness now depends on the same telemetry used to run and secure the platform.
Related NHI Mgmt Group resources: Cyber Resilience Guide · Software Supply Chain Security Guide · Vulnerability Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Continuous audit readiness is a governance and risk management issue in dynamic Kubernetes environments. |
| PR.DS-01 — Data-at-rest is protected | The article emphasises evidence, inventory, and control over operational data used for auditability. | |
| Recommendation — Define a risk strategy that treats runtime evidence as part of continuous governance, not a periodic check. Protect audit evidence and inventory data so runtime records remain trustworthy and tamper-resistant. | ||
| CIS Controls v8 | CIS-5 — Account Management | The runtime drift discussion maps to active control of identities and access within fast-changing environments. |
| Recommendation — Review account and access scope continuously so production permissions stay aligned with runtime state. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Continuous evidence generation directly supports automated audit review and reporting. |
| Recommendation — Automate audit record analysis so compliance evidence is generated from live operational telemetry. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Timestamped proof of runtime state depends on reliable logging and traceability across the platform. |
| Recommendation — Use logging controls to preserve the evidence needed to prove what was running at any point in time. | ||
Key terms
- Compliance Operations (CompOps): A model for making compliance part of day-to-day system operations instead of a periodic audit event. It embeds requirements into version-controlled lifecycle workflows so evidence, policy checks, and control enforcement are produced continuously as systems change.
- Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.
- Policy State Drift: Policy state drift occurs when the permission a system believes is current no longer matches the user's actual choice. In customer data environments, drift creates compliance risk, inconsistent customer experiences, and operational inefficiency because different channels enforce different rules.
- Digest-Accurate Inventory: A live inventory method that records the exact image digest or artifact identity running in production, rather than relying on mutable tags or stale deployment records. It is essential when teams need to prove precisely what was executing during an audit or incident review.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to broader security operations and compliance programmes.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org