Category: Network Security

Virtual Private Network

Also known as: VPN, virtual private network

Simply put

A VPN is a technology that creates a secure, private connection across a public or shared network such as the internet. It is intended to protect data as it travels between networks or between a user and a private network, and can be used to connect remote sites or link on-premises infrastructure with cloud services.

Formal definition

A virtual private network is an overlay network built on top of existing public or shared network infrastructure using network virtualization to extend a private network across an untrusted medium. It is intended to provide a secure communications mechanism for data and IP information transmitted between networks, typically through encryption and authenticated tunneling. In a payment security context, a VPN may be used as one control to protect connectivity between systems, but its presence alone does not define PCI DSS scope or satisfy specific requirements; the applicable controls and requirement wording should be confirmed against the current published PCI DSS. A VPN protects data in transit over the tunnel and does not by itself address protection of stored cardholder data, key management, or endpoint security.

Why it matters

In a payment environment, sensitive traffic frequently traverses public or shared networks—between remote administrators and management interfaces, between on-premises systems and cloud services, or between geographically separated sites. A VPN is intended to protect that data in transit by creating an authenticated, encrypted tunnel across an untrusted medium, reducing the risk that data can be intercepted or altered while it moves between networks. This makes it one common building block in a layered network security design.

However, a VPN's role is often misunderstood. Its presence does not by itself define PCI DSS scope, nor does deploying a VPN automatically satisfy any specific PCI DSS requirement; the applicable controls and requirement wording should be confirmed against the current published standard rather than assumed. A VPN protects data only as it passes through the tunnel—it does not address the protection of stored cardholder data, encryption key management, or the security of the endpoints on either side of the connection. A compromised or misconfigured endpoint can undermine the protection the tunnel is intended to provide.

Because of these limitations, a VPN should be treated as one control among many rather than a comprehensive solution. Sensitive authentication data must not be stored after authorization regardless of whether a VPN is in use, and cardholder data at rest remains subject to its own controls. Teams that rely on a VPN as a single line of defense may overestimate their coverage, so it is best evaluated in the context of overall network segmentation, access control, and endpoint hardening.

Who it's relevant to

Security Engineers

Engineers designing network architectures use VPNs to secure connectivity between sites, remote users, and cloud services. They should treat the VPN as one control protecting data in transit and pair it with endpoint hardening, segmentation, and key management, since the tunnel alone does not secure stored data or the systems at either end.

Compliance Officers

Those assessing PCI DSS compliance should recognize that a VPN's presence does not by itself define scope or satisfy specific requirements. The applicable controls and requirement wording should be confirmed against the current published PCI DSS rather than assuming a fixed requirement number, and the VPN should be evaluated as part of the broader control set.

Cloud and Infrastructure Teams

Teams connecting on-premises infrastructure with public cloud services often rely on VPNs to link environments securely. They should account for the fact that the VPN protects data only while it passes through the tunnel, leaving stored data, key management, and endpoint security to be addressed by separate controls.

Inside VPN

Encrypted tunnel

A VPN establishes an encrypted communication channel between endpoints, intended to protect data in transit across untrusted networks. The strength of protection depends on the protocols, cipher suites, and key management chosen, not on the presence of a VPN alone.

Endpoint authentication

VPNs authenticate the connecting parties, which may involve certificates, pre-shared keys, or user credentials. For remote access into environments handling cardholder data, additional authentication controls such as multi-factor authentication are typically expected; confirm the specific requirement against the current published PCI DSS.

Site-to-site vs. remote-access models

Site-to-site VPNs connect networks (for example, between facilities or to a processor), while remote-access VPNs connect individual users or devices. Each model has different exposure and scoping implications for an environment that transmits or processes cardholder data.

Scope relationship

A VPN is a transmission control; it affects how data moves but does not by itself remove systems from PCI DSS scope. Whether a VPN reduces scope depends on segmentation, implementation, and validation, not on the label.

Common questions

Answers to the questions practitioners most commonly ask about VPN.

Does using a VPN put a system in scope for PCI DSS, or take it out of scope?

A VPN is a network control, not a scoping determinant by itself. Whether systems are in scope depends on whether they store, process, or transmit cardholder data, or can affect the security of the cardholder data environment. A VPN may protect data in transit across untrusted networks, but establishing a VPN does not automatically remove a system from scope, nor does it inherently place an otherwise unrelated system in scope. Scope should be determined by validated segmentation and data flows, not by the presence of a VPN alone.

Is a VPN a form of encryption that satisfies PCI DSS requirements for protecting cardholder data?

A VPN typically provides encryption for data in transit over the network path it covers, but it is not the same as protecting stored cardholder data, and it is distinct from tokenization, truncation, masking, or hashing of data at rest. A VPN addresses transmission across open or untrusted networks; it does not by itself address how cardholder data is stored, nor does it govern sensitive authentication data handling. Confirm the applicable transmission and storage protections against the current published PCI DSS, since requirement wording and numbering differ between versions.

How does a VPN relate to securing transmission of cardholder data across open, public networks?

A VPN can be one mechanism to establish an encrypted channel for transmitting cardholder data across untrusted or public networks, using strong cryptography and secure protocols. The effect on compliance depends on the strength of the cryptography, key management, protocol configuration, and validation, not on the VPN label alone. Review the specific transmission-protection controls in the current PCI DSS version to confirm what is required.

What authentication should be applied to VPN access into the cardholder data environment?

Remote access into the cardholder data environment is generally expected to use multi-factor authentication, which combines factors such as something you know, something you have, and something you are. Multi-factor authentication here addresses access control and is distinct from transaction-time authentication concepts such as EMV chip authentication or 3-D Secure. Confirm the specific access and authentication requirements against the current published PCI DSS, as wording and numbering vary by version.

Does terminating a VPN at the network perimeter mean internal traffic no longer needs protection?

No. A VPN typically protects traffic only across the path it covers, often between endpoints or up to a termination point. Traffic beyond the VPN termination, including internal network segments, may require separate controls. Where cardholder data continues to traverse networks after VPN termination, the applicable transmission and access controls still apply based on data flows and segmentation.

What operational practices help keep a VPN protecting the cardholder data environment effective over time?

Practices intended to help include using strong cryptography and secure, current protocols, disabling weak or deprecated configurations, managing keys and certificates securely, restricting access to authorized users with multi-factor authentication, logging and monitoring access, and reviewing configurations against change. These measures may reduce risk but do not eliminate it, and they do not replace proper scoping, segmentation validation, or the storage protections that apply separately. Verify all configuration expectations against the current published standard.

Common misconceptions

A VPN alone makes remote access to the cardholder data environment PCI DSS compliant.

A VPN is one control among many. Remote access into environments handling cardholder data is generally expected to include additional controls such as multi-factor authentication and appropriate logging. Confirm applicable requirements against the current published PCI DSS rather than assuming a VPN satisfies them.

Because a VPN encrypts traffic, it protects the data everywhere, including at rest.

A VPN protects data in transit within the tunnel. It does not encrypt data at rest, and it does not by itself transform stored cardholder data. Sensitive authentication data must not be stored after authorization regardless of any VPN in use; a VPN does not change that prohibition.

Adding a VPN automatically reduces PCI DSS scope.

Scope reduction depends on effective segmentation and how the VPN is implemented and validated, not on deploying a VPN. A poorly configured VPN can extend connectivity into the cardholder data environment and increase, rather than reduce, the systems in scope.

Best practices

Require strong authentication for remote-access VPN connections into the cardholder data environment, including multi-factor authentication, and verify the specific expectation against the current published PCI DSS.

Use current, well-supported protocols and cipher suites, and maintain a defined key management process rather than relying on default or weak configurations.

Do not treat the VPN as a scope-reduction mechanism on its own; validate any claimed scope reduction through documented segmentation and testing.

Restrict VPN access to the minimum necessary systems and users, applying least-privilege access rather than granting broad network reachability.

Log and monitor VPN connections and authentication events to support detection and investigation, recognizing that monitoring involves false-positive and false-negative trade-offs.

Remember that a VPN protects data in transit only; continue to apply separate controls for data at rest and honor the prohibition on storing sensitive authentication data after authorization.