Primary Functions Requiring Different Security Levels

“Primary functions requiring different security levels” is PCI’s way of forcing a clean separation between workloads that do not belong together from a risk perspective. The classic failure mode is a high-risk or public-facing service (web app, file transfer, remote admin tooling, monitoring agent, developer utilities) co-resident with a more sensitive function tied to payment processing or CDE administration. Once that co-residency exists, a compromise of the weaker function can become a compromise of the stronger one.

Requirement 2.2.3 gives you three compliant patterns: (1) keep one primary function per system component, (2) isolate differing-security functions that must coexist, or (3) apply the highest security level to everything on that component. Your job as a CCO or GRC lead is to turn that into inventory decisions, architecture rules, build standards, and assessor-ready evidence: what runs where, why it’s there, and how you prevented cross-impact.

This page gives requirement-level implementation guidance you can execute quickly: scoping, design decisions, control selection, required artifacts, audit questions, and a practical phased rollout plan.

Regulatory text

PCI DSS 4.0.1 Requirement 2.2.3 states:

“Primary functions requiring different security levels are managed such that only one primary function exists per system component, or primary functions with differing security levels that exist on the same system component are isolated from each other, or primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.” (PCI DSS v4.0.1 Requirement 2.2.3)

What the operator must do

You must be able to show, for each in-scope system component, one of the following is true:

1. Single primary function: the component is dedicated (no mixed workloads), or
2. Isolation: mixed primary functions exist but are separated with enforceable technical boundaries appropriate to the risk, or
3. Highest security level: mixed primary functions exist and the whole component is configured, hardened, monitored, and managed to meet the strictest function’s needs.
   Your assessor will look for both design intent (standards) and real-world proof (inventory, configs, and change records).

Plain-English interpretation (what counts as “primary function” and “different security levels”)

• Primary function: the main purpose of the system component, not every background process. Examples: “web server,” “database server,” “authentication service,” “payment application,” “jump host,” “endpoint management,” “DNS,” “logging/SIEM forwarder.”
• Different security levels: two functions that reasonably need different hardening, access control, exposure, patch urgency, monitoring depth, or change constraints. A public-facing web tier and a CDE administration function are “different security levels” in almost any architecture.

A practical way to interpret the requirement: if one function would drive you to apply stricter controls (tighter admin access, reduced outbound connectivity, stronger monitoring, more conservative change control), then it sets the “highest security need” for any shared component.

Who it applies to

PCI DSS Requirement 2.2.3 applies to:

• Merchants, service providers, and payment processors operating environments that store, process, or transmit cardholder data, or that can impact the security of the CDE (PCI DSS v4.0.1 Requirement 2.2.3).
• Operational contexts where the requirement shows up most:
  • Virtualization hosts and shared VM clusters supporting mixed workloads
  • Container platforms (Kubernetes nodes) hosting both CDE-impacting and non-CDE apps
  • Windows or Linux servers running multiple server roles
  • “Utility” servers (patching, monitoring, remote access, file transfer) placed too close to the CDE
  • Cloud instances that grow organically (one VM becomes three roles over time)

What you actually need to do (step-by-step)

Use this sequence to operationalize the requirement quickly.

Step 1: Decide and publish your allowed patterns

Pick your default posture and document it:

• Preferred: one primary function per system component (simple to defend).
• Allowed with approval: mixed functions only if isolation is designed and validated.
• Fallback: secure to the highest level when isolation is impractical, but accept the broader control scope.

Put this into an engineering standard (build standard, platform policy, reference architecture). Assessors want to see that this is not handled ad hoc.

Step 2: Build an inventory that ties “component → primary function(s)”

For each in-scope component, capture:

• Component identifier (hostname/instance ID), owner, environment, and location/segment
• Primary function(s) and why they’re co-resident (if applicable)
• Administrative access paths (who can administer it and from where)
• Network exposure (ingress/egress, inbound listeners, management interfaces)

If you already have CMDB or cloud inventory, add the “primary function(s)” attribute and make it required in provisioning.

Step 3: Classify functions by security need (simple and defensible)

Create a short rubric your teams can apply consistently:

• High security need: CDE systems, CDE administration systems, payment application components, security tooling that can alter CDE security state.
• Moderate: internal business services with authenticated access and limited blast radius.
• Lower: internet-facing content or services with broad exposure, experimental tooling, or user-driven plugins.

You are not trying to win a taxonomy contest. You are trying to justify why co-residency is or is not acceptable.

Step 4: Remediate mixed-function components using a decision matrix

For each component with mixed security levels, choose one path:

Option	Use when	What “good” looks like	Typical evidence
One primary function per component	You can split roles without breaking operations	Dedicated hosts/instances; clean role boundaries	Decommission plan, new build tickets, updated diagrams
Isolation between functions	Co-residency is required (legacy, platform constraints)	Strong technical separation with limited trust paths	Segmentation rules, hypervisor/container isolation controls, access control proofs
Secure to highest level	Isolation is too complex, but you can apply stricter controls broadly	Hardening, monitoring, admin access, and change controls meet the strictest function	Build standard mapping, configuration baselines, logging/monitoring coverage

Step 5: Define what “isolation” means in your environment

Isolation must be more than “different ports” or “different directories.” Common acceptable approaches depend on your architecture:

• Separate VMs on the same hypervisor with hardened management plane controls and strict network segmentation between VM networks.
• Separate containers with strong runtime controls plus node-level protections, and clear boundaries around secrets and service accounts.
• OS-level separation is usually hardest to defend if two primary functions share the same OS instance. If you take this route, you need very tight service permissions, filesystem protections, and admin access controls, plus a strong rationale.

Write down your approved isolation methods and minimum requirements (for example: no shared admin accounts between functions, separate secrets, restricted inter-process access, and explicit network controls). Your assessor will ask for consistency.

Step 6: Treat “secure to highest level” as a scope-expanding choice

If you secure the whole component to the highest security need, operationalize what that changes:

• Hardening baseline becomes the strictest baseline
• Patch and vulnerability handling follows the strictest timelines you apply internally
• Logging/monitoring becomes CDE-grade (retention, alerting, access review)
• Administrative access is restricted like a sensitive system (jump host controls, MFA, least privilege)
• Change management becomes more controlled

The risk tradeoff: you reduce architectural complexity, but you increase the set of systems that must meet higher controls during audits.

Step 7: Add gates so the problem does not come back

Put controls into the build/procurement lifecycle:

• Cloud provisioning templates require a declared primary function and security level.
• Change requests that add a new server role must trigger a 2.2.3 review.
• Platform teams publish “approved patterns” so application teams do not improvise.
• Third party-provided appliances and managed services get assessed for co-resident functions that could impact CDE security.

Practical note: if you use Daydream to manage third-party risk and due diligence, add a PCI DSS 2.2.3 check to third party onboarding for any hosted payment-related service. Ask the provider to describe workload separation and isolation controls for shared infrastructure that could impact your CDE.

Required evidence and artifacts to retain

Keep artifacts that show design intent, current state, and control operation:

• System inventory/CMDB extract listing each in-scope component and its primary function(s)
• Network/data flow diagrams showing segmentation and trust boundaries for mixed-function areas
• Build standards / hardening baselines stating your one-function, isolation, or highest-level approach
• Exception register for approved mixed-function components, with compensating controls and expiry/review triggers
• Configuration evidence appropriate to your chosen approach:
  • Firewall/segmentation rule evidence
  • Admin access controls (role assignments, MFA enforcement evidence)
  • Logging/monitoring coverage and alert routing for the component
• Change records showing how new roles/services were reviewed for 2.2.3 impact

Common exam/audit questions and hangups

Expect these from a QSA or internal audit:

• “Show me a list of system components and their primary function(s). Where is this maintained?”
• “Which components host multiple primary functions? Why were they approved?”
• “Explain how isolation is enforced. What prevents lateral movement between functions on the same component?”
• “If you chose ‘secure to highest level,’ show the baseline and how you verify it stays in place.”
• “How do you prevent engineers from adding a second role to a server without review?”
• “For shared platforms (virtualization, containers), what protects the management plane and tenant boundaries?”

Hangup to anticipate: teams often confuse “we have VLANs” with “we isolated primary functions.” VLANs may help, but the assessor will still ask how the functions interact on the same component and how administrative access is controlled.

Frequent implementation mistakes (and how to avoid them)

1. Calling everything a single primary function to avoid work
   Fix: require a brief justification for primary function labeling, and review it in architecture or change control.

2. Relying on weak isolation inside one OS
   Fix: prefer separation by instance/VM for different security-level functions. If you must share an OS, document the exact controls that prevent cross-impact and test them.

3. Choosing “secure to highest level” without updating operational processes
   Fix: map what “highest level” means in your environment (admin access, logging, patching, change control) and ensure the system is actually managed that way.

4. No prevention mechanism
   Fix: add build-time attributes (function/security level), approval gates for role changes, and periodic drift reviews.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific actions. Practically, 2.2.3 is assessed as part of core environment hardening and configuration management. The risk is straightforward: co-resident lower-security services can become an access path into higher-security functions, expanding the blast radius of common events like credential theft, remote code execution, or misconfiguration.

Practical execution plan (phased)

Use these phases to drive action without getting trapped in calendar promises.

Immediate phase: stop new mixed-function debt

• Publish the allowed patterns (one function, isolate, or secure-to-highest).
• Add a required “primary function(s)” field to provisioning and major change requests.
• Identify obvious high-risk co-residency (internet-facing + CDE-impacting on one component) and freeze further expansion.

Near-term phase: inventory and remediate the top risk

• Produce the component-to-function inventory for all in-scope systems.
• Triage mixed-function components and pick remediation paths using the decision matrix.
• Document isolation standards and create an exception process with owner sign-off.

Ongoing phase: verify, enforce, and keep evidence current

• Implement periodic reviews of system roles (drift detection, CMDB reconciliation).
• Test isolation controls during security validation (segmentation testing and access reviews).
• Keep diagrams, baselines, and exceptions current so audits do not become archaeology.

Frequently Asked Questions

What is a “system component” for PCI DSS 2.2.3?

Treat it as any server, VM, container node, network device, or cloud instance that supports or can impact the security of the CDE. If it runs workloads or provides services tied to cardholder data security, it belongs in your inventory and review scope.

Is it automatically noncompliant to run two services on one server?

No. PCI DSS 2.2.3 allows multiple primary functions on one component if you either isolate them or secure the entire component to the highest required security level (PCI DSS v4.0.1 Requirement 2.2.3).

What’s the easiest approach to defend to an assessor?

One primary function per system component is the simplest story and usually the simplest evidence set. Isolation and “secure to highest” can be compliant, but they require tighter documentation and stronger operational proof.

Does virtualization count as isolation?

Virtualization can support isolation, but you still need to control the management plane, admin access, and network paths between workloads. Be ready to show how you prevent one workload from affecting another across differing security levels.

If we choose “secure to highest level,” do we pull that system into CDE scope?

“Secure to highest level” does not automatically redefine your PCI scope, but it does mean you must manage that component with CDE-grade controls if the highest-need function requires them. Document the rationale and the control set you applied so your scope narrative stays consistent.

How should we handle third party hosted platforms where we don’t control the underlying host?

Require the third party to explain how they separate or isolate workloads with differing security needs, or how they secure shared components to the highest need. Capture their response and map it to your 2.2.3 approach as part of due diligence.