Continuous validation exposes the gap between compliance and reality

At a glance

What this is: This is an analysis of how moving from annual pentest snapshots to weekly validation changed what a regulated organisation could see about real-world exposure.

Why it matters: It matters to IAM, PAM, NHI, and cloud security teams because standing access, over-permissive permissions, and unmanaged change create risk between scheduled assurance points.

By the numbers:

• One AWS read-only credential was involved in 39 distinct attack paths
• Full AWS account compromise was safely achieved in under 10 minutes

👉 Read Horizons.ai's analysis of continuous validation in regulated environments

Context

Continuous validation is the practice of testing exposure repeatedly as environments change, rather than relying on a once-a-year assessment. In a regulated financial and insurance environment, that distinction matters because cloud, on-prem, outsourcing, and acquisitions can expand attack paths faster than annual assurance cycles can track them. The primary issue is not whether security exists, but whether it is measured at the pace of operational change.

For identity teams, the article is really about privilege drift, hidden attack paths, and the difference between policy on paper and permissions in use. That is where NHI governance, IAM ownership, and PAM controls intersect with broader security validation. When access spans cloud and hybrid infrastructure, the question becomes whether the organisation can prove what an identity can do right now, not what it was allowed to do last year.

Key questions

Q: What breaks when application security relies on annual pentest snapshots?

A: Annual pentest snapshots break down when applications, secrets, and access paths change faster than the next test cycle. Security teams can end up with clean historical evidence while production exposure has already shifted. The result is assurance based on stale observations, which is especially risky for customer-facing apps and identity-dependent integrations.

Q: Why do cloud identities create hidden escalation risk?

A: Cloud identities are risky because their power often comes from relationships, not obvious labels. A read-only account can still connect to administrative roles, storage, or workload controls through inherited policies and automation. That makes escalation a graph problem as much as an access problem. Teams need to inspect privilege chains, not just account types.

Q: How do you know if continuous remediation is actually working?

A: Look for reduced dwell time between risk detection and entitlement change, fewer identities outside lifecycle ownership, and fewer stale permissions surviving the review cycle. If risks remain open until the next campaign, the programme is still operating as a periodic review process rather than a continuous control.

Q: What should teams do when a cloud finding affects identity access?

A: Teams should treat the finding as both a security issue and an identity governance issue. The immediate task is to identify the roles, policies, and delegated permissions that made the path possible, then retest after the fix. That approach is more reliable than relying on owners to confirm the issue is resolved in their own systems.

Technical breakdown

Why annual testing misses living attack paths

Annual pentests capture exposure at a point in time, but modern environments are not static. Cloud accounts, outsourced workflows, inherited permissions, and acquisitions continuously create new relationships between identities, systems, and data. If validation waits months, the organisation is effectively comparing yesterday’s map to today’s terrain. Continuous validation closes that timing gap by repeatedly testing the current environment and replaying attacker paths against live conditions. That is especially relevant in identity-rich environments where permissions change faster than governance records are updated.

Practical implication: move assurance from calendar-based testing to recurring validation tied to environmental change.

How privilege escalation appears in cloud identity graphs

Cloud attack paths often begin with a seemingly low-risk identity, such as a read-only role, and then exploit policy relationships, inherited privileges, or automation-created roles to reach administrative access. The key failure is not just excessive access, but the hidden structure of identity relationships that makes escalation possible. In practice, the graph matters more than the label on the account. A role that looks harmless in isolation can still connect to high-value control planes, sensitive storage, or workload credentials through indirect paths.

Practical implication: map privilege relationships, not just assigned roles, before assuming a low-privilege identity is safe.

Why verified remediation matters more than accepted findings

Traditional remediation workflows often stop at ticket closure, but that leaves a dangerous assumption in place: that the fix actually removed the exploit path. Verification turns remediation into an evidence-based control by retesting the exact weakness after the change. In identity and cloud environments, this is critical because permissions, secrets, and role bindings can survive partial fixes. The article’s core technical lesson is that exploitability must be disproven, not merely assumed absent after a patch or configuration change.

Practical implication: require retesting for every high-risk identity or cloud finding before closing it.

Threat narrative

Attacker objective: The attacker objective is to turn existing permissions into full cloud control and sensitive data exposure without needing malware or a separate exploit chain.

1. Entry begins with a low-privilege AWS credential that still had enough reach to participate in attack path discovery across the environment.
2. Escalation occurred through identity and policy relationships that enabled movement from read-only access to administrative compromise without needing a brand-new foothold.
3. Impact was demonstrated through full AWS account compromise and confirmed access to more than 100,000 sensitive files using permissions already in place.

NHI Mgmt Group analysis

Continuous validation is becoming a governance requirement, not a testing preference. Annual snapshots assume the environment stays stable long enough for the results to remain useful. In cloud and hybrid estates, that assumption fails quickly because permissions, workloads, and third-party access evolve continuously. Practitioners should treat validation cadence as part of control design, not just an operational convenience.

Privilege drift is the named concept this article exposes. The real problem is not simply over-privileged accounts, but the accumulation of hidden paths that make a low-risk identity capable of high-impact compromise. That is a direct IAM and PAM issue, and in NHI-heavy environments it becomes a machine identity governance issue as well. The practical lesson is to govern relationships, not only account inventories.

Closed-loop verification is the difference between remediation and reassurance. Findings lose value if teams cannot prove the attack path disappeared after the fix. This is where NIST Cybersecurity Framework 2.0 and NIST SP 800-53 style control thinking align with identity governance: controls must be observable, repeatable, and re-testable. Practitioners should require evidence that the exploit path no longer exists.

Cloud change velocity breaks compliance-era assurance models. The article shows a regulated organisation operating with strong intent but outdated measurement rhythm. That is common in enterprises where governance, ownership, and technical validation are still partially decoupled. The field should expect more programmes to shift from periodic audits to continuous exposure management.

Identity security is increasingly inseparable from operational security validation. The same access paths that affect cloud compromise also affect NHI governance, because service roles, automation identities, and delegated access can carry the same hidden reach. Teams that manage human IAM without modelling machine access will keep missing the real blast radius.

What this signals

Privilege drift becomes more dangerous as validation cadence slows. The operational signal for readers is clear: if your programme still relies on periodic testing, it will understate current exposure in cloud and hybrid estates. Pair continuous validation with identity governance so that access drift, delegated privileges, and service roles are reviewed in the same rhythm as infrastructure change.

Closed-loop retesting should become a standard control expectation. In practice, this means remediation is not complete until the specific attack path no longer works. That discipline aligns well with NIST Cybersecurity Framework 2.0 and NIST SP 800-53 style control assurance, because both depend on demonstrable control effectiveness rather than documented intent.

Identity programmes need a stronger link between access ownership and exploitability. The article suggests that many organisations know who owns a system, but not how that system can be reached through identity relationships. For NHI and PAM teams, the next step is to make machine access, service roles, and delegated permissions visible in the same governance workflow.

For practitioners

• Adopt continuous exposure validation Replace annual-only pentest assumptions with recurring testing that tracks cloud, on-prem, and third-party change as it happens. Prioritise environments where acquisitions, outsourcing, or rapid cloud adoption have expanded the attack surface faster than governance processes.
• Map identity relationships to attack paths Build a view of how roles, policies, and delegated permissions connect across AWS, Azure, GCP, and hybrid systems. Focus on the attack paths a low-privilege identity can traverse, not only on whether the account is nominally read only.
• Require verification before closure Do not close high-risk findings on the basis of a ticket or patch alone. Re-test the exact exploit path and preserve evidence that the condition no longer works, especially for identity escalation and sensitive data access findings.
• Shorten remediation ownership loops Assign a named owner for every cloud or identity finding and make the remediation workflow repeatable. The goal is to remove the informal handoffs that let exposure persist between discovery, fix, and verification.

Key takeaways

• Annual testing can satisfy a compliance cycle while leaving real attack paths open for months at a time.
• In cloud estates, identity relationships and privilege drift often matter more than the obvious account label.
• Remediation only becomes meaningful when teams retest the exploit path and prove it no longer works.

Key terms

• Continuous validation: Continuous validation is the practice of re-checking user, device, or session risk after login instead of trusting access indefinitely. It recognizes that identity assurance can drift during a session, especially when endpoint state or user context changes after authentication.
• Privilege Drift: Privilege drift is the gradual gap between the permissions an identity was meant to have and the permissions it actually retains. In AI agent environments, drift grows quickly because roles are reused, tasks change, and lifecycle reviews often lag behind deployment velocity.
• Closed-Loop Remediation: A governance process that does not stop at finding risk. It removes or reduces access, confirms the change in the source systems, and keeps evidence that the risky condition stayed fixed. For NHIs, this is the difference between inventory and actual risk reduction.

What's in the full article

Horizons.ai's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how weekly pentesting was operationalised across cloud, on-prem, and third-party environments
• Specific attack-path screenshots and remediation evidence that show how findings were validated and then closed
• The team's workflow for reducing debate by pairing exploit proof with remediation recommendations and retesting
• How the organisation used repeated validation to uncover issues in Active Directory, EDR coverage, and cloud estates

👉 Horizons.ai's full post covers the attack paths, remediation workflow, and retesting model in detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme they already run.