The Great VPN Myth: What PCI DSS 4.0 Actually Requires for Remote Access

"We can’t use Pomerium - we need a VPN for PCI compliance."

I've heard this statement countless times from security teams, and it's completely wrong. Let's go through PCI DSS 4.0 line by line to debunk this expensive misconception. All code snippets available here on Github Gist.

What PCI DSS Actually Says

PCI DSS 4.0 makes exactly zero mentions of VPNs. Instead, here's what it requires for remote access (directly quoted in italics):

Requirement 7.2.5: Access Control

Access is assigned to users, including privileged users, based on:

• Job classification and function.
• Least privileges necessary to perform job responsibilities.

VPNs give network-level access - the opposite of least privilege. They're the equivalent of giving someone keys to your entire building when they only need to access one room.

Requirement 8.2.2: Multi-Factor Authentication

MFA is implemented for all access into the CDE for personnel with administrative access.

Notice it doesn't specify how MFA should be implemented. VPNs often bolt on MFA as an afterthought, leading to fragmented security policies.

Requirement 10.2.1.1: Audit Trails

All individual user access to cardholder data is logged.

This is where VPNs spectacularly fail. A VPN log shows:

What happened in between? You have no idea. That's 10 hours of unlogged activity within your cardholder data environment.

Request-level logging - not session-level

VPNs only show when someone connected and disconnected. Contrast that with Pomerium, which continuously verifies every user action and provides detailed audit logs:

VPNs are blind to what the user is doing, however, Pomerium sees and captures what someone is doing (or trying to do). Therefore, with every single user request we capture:

• Who made it (user ID and email)
• What they accessed (path and method)
• When it happened (precise timestamp)
• Why it was allowed (policy matches)
• Complete session tracking

And when access is denied, you get clear reasons why:

This level of logging gives you:

• Complete audit trails for PCI compliance
• Instant visibility into access patterns
• Clear accountability for every action
• Easy troubleshooting of access issues

Requirement 12.3.3: Remote Access

Remote access to the CDE is enabled only when needed by vendors and business partners, with immediate deactivation after use.

Try doing that with a VPN. You'll need complex networking rules, jump boxes, and probably several support tickets just to enable and disable access.

Modern Implementation: Context-Aware Access

Let's look at how a modern context-aware proxy like Pomerium actually implements these requirements:

1. Least Privilege Access (7.2.5)

This policy ensures:

• Users must be authenticated
• Must belong to the authorized finance group
• Can only access specific paths
• Must use an approved secure device
• Must present valid certificates

2. Time-Limited Vendor Access (12.3.3)

3. Administrative Access with MFA (8.2.2)

Each of these policies provides:

• Per-request authentication
• Complete audit trails
• Device-based security
• Fine-grained access control
• Time-based restrictions when needed

Why This Matters: The Real Requirements

What PCI DSS actually cares about:

1. Identity-based access control - not network perimeter

• Every request must be authenticated
• Access based on user identity and role
• Fine-grained permissions

1. Request-level logging - not session-level

• Who accessed what
• When access occurred
• Why access was granted
• What actions were taken

1. Dynamic authorization - not static network access

• Time-based controls
• Location-based controls
• Device-based controls
• Purpose-based access

1. Zero Trust Architecture - not perimeter security

• Never trust, always verify
• Per-request authentication
• Continuous authorization

The Cost of Clinging to VPNs

The real cost isn't just in VPN licenses - it's in:

1. Expanded Attack Surface

• Unnecessary network exposure
• Overly broad access grants
• Limited visibility into actual usage

1. Operational Overhead

• Complex network rules
• Multiple security tools
• Manual access management

1. Audit Gaps

• Session-level logging only
• Limited user activity visibility
• Incomplete access records

1. Security Incidents

• Network-level compromises
• Lateral movement
• Data exfiltration risks

Moving Forward: Modern Access Control

Here's a complete example of a PCI-compliant access policy using Pomerium:

This single policy implements:

• Strong identity verification
• Device-based security
• Certificate validation
• Time-based access control
• Granular method restrictions
• Complete audit logging
• Zero trust architecture

Conclusion

The next time someone tells you "we need a VPN for PCI compliance," send them this article. Better yet, send them the PCI DSS 4.0 standard itself. The myth of mandatory VPNs needs to die - it's costing companies money and making them less secure.

PCI DSS cares about protecting cardholder data, not how you connect to your network. Choose solutions that actually implement the standard's requirements, not those that just check a legacy compliance box.

Modern context-aware access solutions like Pomerium align perfectly with PCI DSS requirements because they:

1. Focus on protecting resources, not networks
2. Log every interaction, not just connections
3. Enforce granular policies, not network access
4. Enable true zero trust, not perimeter security

Remember: compliance should make you more secure, not just tick boxes. It's time to move beyond VPNs and embrace modern access control.