TL;DR: Legacy VPN and firewall models leave audit gaps because they cannot continuously enforce context-aware, least-privilege access, according to Appgate’s webinar on modern compliance. The control problem is not just perimeter weakness; it is the mismatch between static access assumptions and dynamic regulatory expectations.
At a glance
What this is: This webinar argues that compliance now depends on zero trust access control, because legacy VPN and firewall models cannot deliver the continuous, context-aware enforcement auditors expect.
Why it matters: IAM and security teams need access controls that prove least privilege and traceability in real time, not just at login, across both human and non-human access paths.
Context
Compliance frameworks now expect access decisions to be context-aware, traceable, and continuously enforced, which means network boundaries alone are no longer enough. The practical gap is not just perimeter weakness but the mismatch between static access assumptions and dynamic regulatory expectations.
This is an identity governance problem as much as a network security one. When access is granted through legacy VPNs or firewall rules, organisations often lose the resource-level evidence needed to show who had access, under what conditions, and whether that access stayed within policy.
Key questions
Q: What breaks when organisations rely on VPNs for modern remote access?
A: VPNs tend to extend network trust more broadly than modern risk models allow. In distributed environments, that can expose too much of the internal network once a user connects, especially when personal devices and cloud applications are involved. Browser-mediated access narrows the trust boundary to the session rather than the network.
Q: Why do zero trust access controls help with audit and regulatory requirements?
A: Zero trust helps because it makes the access decision itself auditable. Instead of logging only that a user connected, it can record the identity, device posture, context, and resource involved. That gives compliance teams a defensible trail for least privilege, segmentation, and continuous enforcement.
Q: What signs suggest access control is too broad across business systems?
A: Look for identities that can move from one sensitive platform to another without a clear business reason, especially where ticketing, source control and employee data are reachable through the same entitlement set. Repeated approval chains and shared administrative paths are common indicators of excessive scope.
Q: How should security teams implement zero trust for regulatory compliance?
A: They should start by mapping each regulatory obligation to a specific identity, access, logging, or encryption control, then verify those controls in production. Zero trust only supports compliance when access is continuously checked, privilege is limited, and evidence can be produced quickly for audit or incident review.
Technical breakdown
Why perimeter access control fails compliance audits
Legacy VPNs and firewalls were built around the idea that a trusted network boundary could substitute for continuous authorisation. That model breaks down when compliance expectations require context-aware decisions, segmentation, and proof that access remained appropriate after the initial login. Once a user is on the network, flat visibility and broad reach undermine least privilege and make lateral movement easier to justify in an audit finding. The control failure is architectural: the security boundary sits too far from the resource being protected, so the organisation cannot prove that access was constrained at the point of use.
Practical implication: Move enforcement from the network edge to the resource boundary so audit evidence reflects actual access decisions.
How dynamic least privilege changes the evidence model
Zero trust access control replaces static entitlements with policies that evaluate identity, device posture, role, and context each time access is requested. That matters because compliance is no longer just about whether access was granted, but whether it was granted for the right reason and stayed within acceptable conditions. In practice, this creates a much cleaner evidence trail than VPN connection logs, because the access decision itself becomes auditable. It also reduces entitlement creep, which is a common source of over-permissioned access in both regulated and non-regulated environments.
Practical implication: Treat policy decisions as audit artefacts and verify that access logs capture the reason for each grant.
Why continuous endpoint validation matters for regulated access
A compliant access model cannot assume that a device is safe just because the user authenticated successfully. Continuous validation checks device health, patch state, encryption, and management posture before and during the session, which is the difference between one-time admission and ongoing trust. That distinction matters in regulated environments because a device that falls out of compliance after login can still expose sensitive systems if access is not re-evaluated. The real issue is not only authentication strength, but whether the access path can respond when endpoint trust changes mid-session.
Practical implication: Tie session continuity to endpoint posture so compliance evidence includes device state, not only user identity.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
- CitrixBleed 2 2025: CitrixBleed 2 leaked NetScaler session tokens from memory, letting attackers hijack VPN sessions and skip MFA at 100+ organisations.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Compliance now depends on access enforcement, not access policy alone: Static rules are no longer enough when regulators expect evidence that access was constrained continuously and contextually. The old assumption was that a login event proved sufficient trust for the whole session. That assumption breaks under zero trust because trust must be re-evaluated as conditions change, so practitioners need to treat access enforcement as an ongoing control plane, not a one-time gate.
Auditability is becoming a design requirement, not a reporting afterthought: Organisations still relying on VPN logs or firewall records are often unable to show resource-level who, what, when, where, and why evidence. That gap turns compliance from a documentation exercise into a control design problem. The named concept here is audit evidence at the point of access: if the control cannot explain the decision in session, it will struggle to satisfy modern assurance expectations.
Zero trust exposes entitlement creep as a compliance issue: Over-permissive access is not just a security hygiene problem; it is a direct challenge to least-privilege attestations and segregation expectations in frameworks such as PCI DSS and ISO 27001. When users can see more of the network than their role requires, the organisation loses the ability to defend scope boundaries. The implication is that governance teams must measure access scope as a compliance control, not as an optional optimisation.
Continuous endpoint validation closes a gap that identity alone cannot solve: Identity proof at login does not tell you whether the device remains acceptable two minutes later. That is why access control for regulated systems has to combine identity, device posture, and context into one decision loop. For practitioners, the compliance question is no longer whether MFA exists, but whether access can be revoked when the trust context changes.
Legacy perimeter models are now a governance liability: The broader market signal is that access architecture is moving from network-centric assurance to identity-centric assurance. That shift affects IAM, PAM, and compliance programmes at the same time because evidence, enforcement, and privilege scope are converging. Teams that separate security architecture from audit readiness will keep rediscovering the same control gap in different forms.
What this signals
Audit evidence at the point of access: Compliance programmes increasingly need proof generated during the access decision itself, not reconstructed later from network logs. That means IAM, PAM, and security architecture teams have to treat logging, authorisation, and session continuity as one design problem.
Zero trust makes entitlement scope visible in a way perimeter models never could. The programme signal for practitioners is that least privilege must be measured against actual resource access, because coarse network access leaves too much room for audit ambiguity.
Access review processes become weaker when the control only sees group membership or VPN login history. If the review artefact cannot show current device posture, context, and resource scope, it is describing access in the abstract rather than governing it in practice.
For practitioners
- Replace network-wide trust with resource-level policy enforcement Map every protected application or data path to a policy that evaluates identity, device posture, role, and context before granting access. Use the protected resource itself as the enforcement boundary, not the VPN tunnel.
- Inventory where audit evidence is still network-centric Review whether your current logs show only session establishment or whether they also capture who accessed which resource, under what conditions, and why access was granted. If the answer is only session-level visibility, compliance evidence is incomplete.
- Tie endpoint posture to session continuity Require device health checks at connection time and re-check them when trust conditions change, including patch state, encryption, and management enrollment. Access should be revocable when endpoint posture no longer meets policy.
- Document least privilege as an auditable control objective Define what least privilege means in terms of actual resource scope, not just roles or group membership. Then test whether access logs and entitlement reviews can prove that scope stayed narrow enough for the regulated workload.
Key takeaways
- Legacy perimeter controls can no longer prove that access stayed within policy once a session begins.
- The compliance challenge is evidence quality as much as enforcement quality, because auditors need context, scope, and continuity.
- Teams should shift from network-centric trust to resource-level authorisation if they want access controls that stand up to modern regulatory expectations.
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, NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on least-privilege access and auditable authorisation decisions. |
| PR.DS-10 — Data-in-transit is protected | Zero trust access enforcement protects sensitive resources over active session paths. | |
| Recommendation — Map access policies to PR.AA-05 and verify that every grant is scoped to current entitlement and context. Use PR.DS-10 to ensure sensitive access paths are protected during transit and session use. | ||
| NIST Zero Trust (SP 800-207) | Section 2.2 — Zero Trust Architecture Principles | The article directly argues for continuous verification and resource-centric access control. |
| Recommendation — Apply zero trust principles to move enforcement from network boundaries to the protected resource. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is a primary control expectation in the article's compliance argument. |
| Recommendation — Use AC-6 to constrain access scope and prevent broad network entitlements from exceeding job need. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's focus on controlled, auditable access aligns with account governance and privilege scope. |
| Recommendation — Apply CIS-5 to keep account access aligned with current role, device, and policy conditions. | ||
Key terms
- Zero Trust Access Management: Zero Trust access management is the practice of making every access decision explicit, contextual, and continuously reassessed. It replaces blanket trust in a network zone with identity, device, and risk-based policy that can change during a session. In mature programmes, it governs both human and non-human actors.
- Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
- Interaction-Level Audit Evidence: Records that show what an AI system said, when it disclosed its nature, how it handled risky content, and whether it escalated appropriately. This evidence is essential when compliance, safety, or legal teams need to prove the system behaved within its intended boundaries.
- Continuous Endpoint Validation: Ongoing checks that confirm a device still meets security policy after access is granted, including posture, patch state, and management status. For regulated access, this prevents a device from becoming non-compliant mid-session while still retaining access to sensitive systems.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org