Security Controls for Dual-Network Devices

PCI DSS 4.0.1 Requirement 1.5.1 requires you to identify any device that connects to both the internet (or other untrusted networks) and the cardholder data environment (CDE), then enforce security controls that are (1) specifically configured to block threat introduction, (2) actively running, and (3) not user-tamperable except by documented, time-limited management approval. (PCI DSS v4.0.1 Requirement 1.5.1)

Key takeaways:

• Scope and inventory are the hard part: you must find every “dual-network” endpoint, including BYOD. (PCI DSS v4.0.1 Requirement 1.5.1)
• Controls must be enforceable and provable: “running” and “not alterable” implies centralized management plus monitoring evidence. (PCI DSS v4.0.1 Requirement 1.5.1)
• Exceptions are allowed, but only case-by-case, documented, authorized, and time-limited. (PCI DSS v4.0.1 Requirement 1.5.1)

“Dual-network devices” are endpoints that can act as a bridge into your CDE: they touch the internet (or other untrusted networks) and also have connectivity into CDE systems. In practice, these are often admin workstations, POS support laptops, jump hosts, IT staff machines that manage CDE assets, and employee-owned devices used for remote support. They are common, easy to miss, and frequently under-controlled because they sit between endpoint security and network segmentation ownership.

Requirement 1.5.1 forces an operational stance: you must define hardened configurations for these devices, keep protective controls running, and prevent users from weakening those controls unless management explicitly approves a short-lived exception. (PCI DSS v4.0.1 Requirement 1.5.1) For a CCO or GRC lead, the fastest path is to treat this as an endpoint governance problem with three deliverables: (1) a defensible list of in-scope devices, (2) a standard “dual-network device” build profile enforced by MDM/EDR, and (3) evidence that proves both enforcement and exception handling.

Regulatory text

PCI DSS 4.0.1 Requirement 1.5.1 states that security controls must be implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE, such that: (a) specific configuration settings are defined to prevent threats being introduced into the entity’s network, (b) security controls are actively running, and (c) security controls are not alterable by users unless specifically documented and authorized by management on a case-by-case basis for a limited period. (PCI DSS v4.0.1 Requirement 1.5.1)

Operator translation: you must (1) find every endpoint that can reach the CDE and also touches untrusted networks, (2) harden it with an agreed configuration baseline, (3) run protective tooling continuously, and (4) technically and procedurally prevent users from disabling or modifying the protections except through a controlled, time-bound exception process. (PCI DSS v4.0.1 Requirement 1.5.1)

Plain-English interpretation (what the requirement is really testing)

Assessors are looking for two things:

1. A credible scoping method for dual-network devices (not a guess). If you cannot explain how you find them, you cannot prove you covered them.

2. Tamper-resistant endpoint security on those devices. “Actively running” plus “not alterable by users” means local admin rights, unmanaged BYOD, or “best effort” agent installs will trigger follow-up questions unless you have compensating technical controls and tight exception governance. (PCI DSS v4.0.1 Requirement 1.5.1)

Who it applies to

Entities: Merchants, service providers, and payment processors in PCI DSS scope. (PCI DSS v4.0.1 Requirement 1.5.1)

Operational context: Any environment where endpoints can access CDE networks or systems while also using the internet or other untrusted networks. Common in-scope device patterns:

• IT admin workstations used to manage CDE servers, firewalls, hypervisors, or databases.
• Support laptops used to connect to POS/CDE troubleshooting tools, then used on general networks.
• Jump boxes / bastion hosts that have paths into the CDE and also allow browsing or email.
• BYOD used for CDE access via VPN, remote desktop, VDI, or privileged access tooling. (PCI DSS v4.0.1 Requirement 1.5.1)

A simple rule that helps scoping: if a device can reach the CDE (directly or via management plane) and also reaches the internet, treat it as dual-network until proven otherwise.

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

Step 1: Define “dual-network device” in your PCI scoping standard

Write a short definition your teams can apply consistently:

• Untrusted network connectivity (internet, guest Wi‑Fi, home network, cellular hotspot).
• Plus any connectivity that reaches the CDE, CDE management interfaces, or systems that can affect CDE security. (PCI DSS v4.0.1 Requirement 1.5.1)

Step 2: Build and maintain the device population (inventory + tagging)

Create a repeatable method to identify candidates:

• Pull device lists from MDM, EDR, directory services, VPN, and NAC (whatever you have).
• Correlate with access paths into the CDE: VPN groups, PAM/jump host access logs, firewall rules, VDI pools used for CDE administration.
• Tag devices as Dual-Network: Yes/No in your asset inventory, and record the basis (example: “Member of CDE-admin VPN group”).

The audit win here is not perfection; it is a documented method plus periodic reconciliation that shows you actively manage the list. (PCI DSS v4.0.1 Requirement 1.5.1)

Step 3: Define “specific configuration settings” as an enforceable baseline

Document a baseline configuration for dual-network devices that maps to “prevent threats being introduced.” (PCI DSS v4.0.1 Requirement 1.5.1) Your baseline should include, at minimum:

• Host firewall configuration (deny-by-default inbound; restrict outbound if feasible).
• Anti-malware/EDR required settings (real-time protection on, cloud protection on if available, tamper protection on).
• Disk encryption required.
• Strong authentication (MFA for CDE access paths; disable shared accounts).
• Patch/update configuration (automatic updates, or centrally managed patching).
• Browser and macro hardening appropriate for your environment (reduce drive-by risk).
• Removal of local admin rights for standard users; controlled privilege elevation for admins.

Keep the baseline in a standard format: versioned configuration standard + implementation method (MDM profile, GPO, EDR policy).

Step 4: Ensure controls are “actively running” (continuous health, not one-time install)

You need operational assurance, not screenshots from last quarter:

• Central console shows agent coverage for the dual-network tagged population.
• Alerts or tickets for “agent not reporting,” “protection disabled,” “definitions outdated,” or equivalent health states.
• A remediation workflow (helpdesk or security operations) that restores compliance and documents closure. (PCI DSS v4.0.1 Requirement 1.5.1)

Step 5: Make controls “not alterable by users” (technical enforcement + RBAC)

This is where many programs fail. You must prevent a user from turning off protection “because it was slowing my laptop down.” (PCI DSS v4.0.1 Requirement 1.5.1) Practical patterns:

• Enable EDR/AV tamper protection and restrict uninstall/disable to security admins.
• Enforce MDM profiles that are non-removable without admin action.
• Restrict local admin rights; use privileged access management for elevation.
• Lock down firewall settings and logging controls via centralized policy.

Step 6: Implement a case-by-case, time-limited exception process

Requirement text explicitly allows exceptions, but only if documented and authorized by management for a limited period. (PCI DSS v4.0.1 Requirement 1.5.1) Build:

• An exception request form (business justification, device ID, control impacted, start/end date, approver, compensating safeguards).
• A required risk sign-off (security + business owner; “management” approval).
• Technical implementation notes (who changed what, how you revert, what monitoring is in place).
• Automatic review/removal at end date (calendar, ticket SLA, or workflow).

Step 7: Validate with testing an assessor will accept

Run checks that align to the three clauses:

• Config baseline applied (policy assignment evidence).
• Controls running (agent health reports).
• Non-alterability (attempted disable/uninstall tests on a sample device, plus RBAC evidence). (PCI DSS v4.0.1 Requirement 1.5.1)

If you want to move faster, Daydream can act as the system of record for the device population, exception approvals, and evidence packets, so you can answer “which devices are dual-network and how do you know?” without assembling spreadsheets during the assessment.

Required evidence and artifacts to retain

Keep evidence that proves each part of the requirement:

Scope and identification

• Asset inventory extract showing the dual-network tag and owner.
• Data sources and query logic used to identify devices (VPN group mapping, PAM access roster, NAC rules, etc.).
• A scoping procedure describing how devices enter/exit the dual-network population. (PCI DSS v4.0.1 Requirement 1.5.1)

Defined configuration settings

• Versioned hardening standard for dual-network devices.
• MDM/GPO/endpoint policy configurations (exports or screenshots) that implement the standard. (PCI DSS v4.0.1 Requirement 1.5.1)

Controls actively running

• EDR/AV/host firewall compliance reports for the tagged population.
• Ticketing evidence for remediations (agent reinstall, re-enable protection).
• Monitoring/alerting rules and response procedures. (PCI DSS v4.0.1 Requirement 1.5.1)

Controls not alterable

• RBAC model for endpoint security consoles.
• Proof of tamper protection configuration.
• Local admin restriction policy and exception list (if any). (PCI DSS v4.0.1 Requirement 1.5.1)

Exceptions

• Approved exception records with start/end dates.
• Management authorization and security review.
• Evidence of compensating monitoring and closure at expiry. (PCI DSS v4.0.1 Requirement 1.5.1)

Common exam/audit questions and hangups

Expect these:

• “Show me all devices that can access the CDE and also access the internet. How do you know this list is complete?”
• “Which controls prevent users from disabling EDR/AV? Demonstrate on a device.”
• “Do employees have local admin? If yes, explain how controls remain non-alterable.”
• “How do you handle BYOD used for CDE access?”
• “Show an example exception. Who approved it, and how did you ensure it ended?” (PCI DSS v4.0.1 Requirement 1.5.1)

Hangup pattern: teams provide a policy statement but cannot prove enforcement in tooling, or they can prove tooling health but cannot prove scoping completeness.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating this as ‘anti-virus installed’ only. Fix: map each clause to specific, testable controls: baseline config, running health, tamper resistance. (PCI DSS v4.0.1 Requirement 1.5.1)
• Mistake: Missing admin workstations and jump hosts. Fix: build scoping from access paths (VPN groups, PAM entitlements), not only from subnet membership.
• Mistake: BYOD allowed to access CDE with no enforceable controls. Fix: require managed device enrollment for any CDE access path, or block BYOD from CDE connectivity.
• Mistake: Exceptions without expiry. Fix: enforce end dates in the workflow and require re-approval for extensions. (PCI DSS v4.0.1 Requirement 1.5.1)
• Mistake: Users can disable protections “temporarily.” Fix: enable tamper protection and restrict disable/uninstall permissions in the console. (PCI DSS v4.0.1 Requirement 1.5.1)

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement. The risk logic is straightforward: a dual-network endpoint is a common ingress point for malware and credential theft, and it can bypass segmentation if it has privileged connectivity into the CDE. Requirement 1.5.1 pushes you toward preventing that endpoint from becoming a bridge. (PCI DSS v4.0.1 Requirement 1.5.1)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + minimum enforcement)

• Publish your dual-network device definition and scoping procedure.
• Produce the first dual-network device inventory list from available sources; assign owners.
• Confirm EDR/AV is deployed to the full list and reporting centrally.
• Turn on tamper protection and lock uninstall/disable permissions to security admins. (PCI DSS v4.0.1 Requirement 1.5.1)

By 60 days (baseline + monitoring + exception workflow)

• Finalize and approve the hardened baseline standard for dual-network devices.
• Implement baseline via MDM/GPO and validate on a sample across OS types.
• Set up health monitoring and ticketed remediation for non-reporting or non-compliant devices.
• Launch the time-bound exception workflow with management authorization requirements. (PCI DSS v4.0.1 Requirement 1.5.1)

By 90 days (prove it to an assessor)

• Run a reconciliation: devices with CDE access entitlements vs your dual-network tag list; close gaps.
• Conduct a control test: attempt to disable protections as a standard user; capture results and remediation steps.
• Build an evidence packet template (scope, configs, health reports, RBAC, exceptions) so audits are repeatable.
• If you use Daydream, configure it to track the population, approvals, and evidence exports so you can regenerate the packet on demand.

Frequently Asked Questions

What counts as an “untrusted network” for dual-network device scoping?

PCI DSS explicitly includes the internet as untrusted, and you should treat any non-CDE network you don’t fully control (home, guest Wi‑Fi, public hotspots) as untrusted for this purpose. The key test is whether threats from that network could reach the device that also connects into the CDE. (PCI DSS v4.0.1 Requirement 1.5.1)

Are employee-owned (BYOD) laptops in scope if they use VDI to reach the CDE?

If the BYOD device connects to untrusted networks and also has a path to the CDE (even via remote access tooling), it is in scope for this requirement unless you can technically prevent it from being that bridge. Many teams solve this by requiring managed endpoints for any CDE access path. (PCI DSS v4.0.1 Requirement 1.5.1)

Does “not alterable by users” mean no one can change settings?

It means the device user cannot weaken the required controls. Admins can change settings through controlled access and documented processes; user-driven changes require case-by-case, time-limited management authorization. (PCI DSS v4.0.1 Requirement 1.5.1)

What’s the minimum evidence an assessor will accept that controls are “actively running”?

Provide central-console reports showing the controls are installed and healthy on the dual-network device list, plus records of how you remediate devices that stop reporting or fall out of compliance. One-off screenshots without population coverage usually trigger deeper sampling. (PCI DSS v4.0.1 Requirement 1.5.1)

How do we handle contractors or third parties who need to administer CDE systems?

Treat their endpoints like any other dual-network device: enforce required configurations and tamper resistance, or require they connect through a controlled, managed jump environment where you can enforce the controls. Document any time-limited exceptions with management approval. (PCI DSS v4.0.1 Requirement 1.5.1)

Can we meet this requirement purely with network controls instead of endpoint controls?

Requirement 1.5.1 specifically calls for security controls on the computing devices themselves, including defined configurations, active operation, and non-alterability by users. Network controls help, but they do not replace device-level controls under this text. (PCI DSS v4.0.1 Requirement 1.5.1)