skip to content

Should a campus card-payment zone be a VRF on the shared routers or a physically separate network, and how does each choice change PCI DSS scope?

level: principalimportance: should knowfreq 14%

answer

  1. scope follows connection
  2. segmentation shrinks scope, not required
  3. shared routers enforce the separation
  4. a leak makes a connected system
  5. segmentation must be tested

basics

~20 s

Both can shrink PCI DSS scope. A payment VRF on shared routers is cheap but puts every router and switch carrying it into scope and relies on configuration discipline; separate hardware costs more but keeps scope and blast radius small.

solid answer

~50 s

PCI DSS, the card industry's security standard, scopes the **cardholder data environment** plus the systems connected to it or able to affect its security. Segmentation is not required, but without it the whole flat network is in scope; if you rely on it to reduce scope, it has to be tested. A **payment VRF on shared routers** reuses the campus: terminals on any floor land in a payment VLAN and VRF, and a firewall is the only way in or out. But every router and switch that carries that VRF enforces the separation, so it is in scope, and one leak or misbound interface joins the zones. **Separate hardware** keeps scope to dedicated gear and the firewall, at the cost of duplicate switches, cabling and spares. The answer depends on how many payment locations there are, how good change control is, and what the assessor accepts.

go deeper

for a junior

Recall that payment systems are assessed under a card-industry standard and that keeping them in their own zone shrinks what gets assessed.

for a middle

Explain scope as the payment environment plus whatever connects to it, and why a leaked shared-services route pulls those servers in.

for a senior

Show that every device carrying the payment VRF enforces the separation, so it joins the scope, and list the misconfigurations that would join the zones.

for a principal

Choose between shared VRF, dedicated access gear and full separation by payment footprint, change discipline and yearly audit cost, and agree the approach with the assessor early.

## What the standard asks, as far as it is certain The **Payment Card Industry Data Security Standard** (PCI DSS) is published by the PCI Security Standards Council; its text is not part of the networking RFCs, so only its well-established scoping ideas are used here: - The **cardholder data environment** (CDE) is the people, processes and systems that store, process or transmit card data. - Scope covers the CDE **plus** system components connected to it or able to affect its security. - **Segmentation is not a requirement**, but without it the whole network is in scope. Segmentation is how a design shrinks the assessment. - When segmentation is used to reduce scope, the standard requires **penetration testing** that confirms the segmentation controls work, at least every twelve months and after changes to those controls (more often for service providers). The routing question is therefore: which devices end up "connected to or able to affect" the payment zone under each design? ## Option A: a payment VRF on the shared campus Payment terminals on every floor connect to payment VLANs, those VLANs' gateways are bound to a `PAY` VRF, `PAY` is carried hop by hop like every other zone, and the inter-zone firewall is the only device with an interface in both `PAY` and anything else. - **Gains:** no new switches; terminals can be placed anywhere; the firewall is the single policy point. - **Scope cost:** every access switch, distribution router and core router that carries `PAY` is enforcing the separation. A change on any of them, even one meant for `CORP`, can affect the payment zone, so those devices come into scope: hardened configurations, change control, logging and review apply to the shared estate. - **Risk:** separation depends on configuration staying correct. One route leak into `PAY`, one subinterface in the wrong VRF, or one access port on the wrong VLAN connects the zone with no firewall in the path. ## Option B: physically separate payment network Payment terminals plug into dedicated switches with dedicated uplinks to the firewall. - **Gains:** in-scope network gear is the dedicated switches and the firewall; a mistake on corporate devices cannot reach the payment zone; the blast radius of a corporate incident stops at the firewall. - **Costs:** duplicate switches, cabling, optics and spares at every location with terminals; a second estate to patch and monitor; redundancy for it doubles again. ## Middle grounds | Design | In-scope network gear | Cost | Main risk | |---|---|---|---| | `PAY` VRF across the shared campus | Every device carrying `PAY` | Low | Configuration error joins zones | | Dedicated access switches, `PAY` VRF on shared core | Those switches plus the core | Medium | Core misconfiguration | | Fully separate network | Dedicated gear plus firewall | High | Cost and drift of a second estate | Another lever is to reduce what the campus carries: if terminals encrypt card data end to end to the processor, the campus moves ciphertext. Whether that removes devices from scope depends on a validated solution and the assessor's view, so treat it as a question for the assessor rather than a design assumption. ## The shared-services trap Whichever option you pick, watch what the payment zone talks to. If DNS and DHCP are reached by leaking the shared-services prefix into `PAY`, those servers are now systems connected to the CDE, and they join the scope. Common answers are dedicated DNS and DHCP for `PAY`, or reaching shared services only through the firewall with narrow rules; even then, expect the assessor to ask about those servers. ## How to decide 1. **Count payment locations.** Two tills in one store favour dedicated switches; terminals on every floor of many buildings favour a VRF. 2. **Judge change discipline honestly.** A VRF design is only as strong as the team's ability to keep every device's configuration correct and reviewed. 3. **Price scope, not just hardware.** Bringing the whole campus network into assessment costs audit effort every year. 4. **Agree the approach with the assessor early.** They decide what counts as adequate segmentation and will test it. There is no single right answer; a principal-level answer names the scope consequence of each option, the operational risk, and the deciding factors.

  • The assessor's segmentation test from the corporate zone reaches a payment terminal. Where do you look first in a VRF design?
    At where the tables meet outside the firewall: route leaks into or out of the payment VRF, any router interface or access-VLAN gateway bound to the wrong VRF, and access ports placed on a payment VLAN by mistake. Then check whether the payment VRF's routes to corporate prefixes all point at the firewall, as they should.
  • Why is a VRF on shared routers weaker evidence of isolation than a firewall rule set, even though both are configuration?
    A firewall exists to enforce policy and logs what it refuses. VRF separation is a side effect of routing configuration spread over many devices, edited for many reasons, and a mistake simply forwards traffic with no record. That is why VRF designs still insert a firewall at the only point the payment VRF meets anything else.

saying these in an interview costs you the question

  • PCI DSS requires the payment zone to be on physically separate hardware.
  • Putting payment traffic in its own VRF takes the shared routers out of scope.
  • Segmentation is mandatory under PCI DSS for every merchant.
  • Leaking shared DNS into the payment VRF has no effect on scope.
  • Once the segmentation is designed, it never needs to be tested.