Third-Party Remote Access Accounts

PCI DSS 4.0.1 requires you to tightly control third-party remote access accounts: only enable them for the specific time they’re needed, disable them immediately when not in use, and monitor their activity for anything unexpected (PCI DSS v4.0.1 Requirement 8.2.7). To operationalize this fast, implement just-in-time enablement, time-bound approvals, session logging, and alerting tied to third-party identity and access paths.

Key takeaways:

• Keep third-party remote access accounts disabled by default; enable only for approved work windows (PCI DSS v4.0.1 Requirement 8.2.7).
• Monitoring must detect unexpected activity, not just collect logs (PCI DSS v4.0.1 Requirement 8.2.7).
• Auditors will ask you to prove “enabled only when needed” with tickets, timestamps, and access logs that reconcile.

“Third-party remote access accounts requirement” usually fails in practice for one reason: organizations treat third-party access like normal user access. PCI DSS doesn’t. Requirement 8.2.7 forces a higher bar because third parties often connect from outside your managed endpoints, through less familiar networks, and on irregular schedules. That mix creates blind spots: stale accounts left enabled for months, shared credentials, unclear ownership, and monitoring that exists in a SIEM but is not tied to a specific third-party access path.

This requirement is also operationally straightforward if you draw a clean boundary around the scope: any account a third party uses to remotely access, support, or maintain system components. Your job is to (1) keep those accounts disabled until a defined need exists, (2) enable them for a narrowly defined time window, then disable again, and (3) monitor usage for unexpected activity (PCI DSS v4.0.1 Requirement 8.2.7).

The rest of this page gives you a requirement-level playbook: who owns what, what workflows to implement, what evidence to retain, and what auditors commonly challenge.

Regulatory text

Requirement statement (quoted): “Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows: enabled only during the time period needed and disabled when not in use, and use is monitored for unexpected activity.” (PCI DSS v4.0.1 Requirement 8.2.7)

Operator interpretation (what you must do):

1. Identify the population of accounts that third parties use for remote access into in-scope system components.
2. Make the default state “disabled.” A third party should not have standing remote access just because there is a contract.
3. Use time-bounded enablement tied to a legitimate support window (approved work, known target systems, known method of access).
4. Monitor the access in a way that can surface unexpected activity (for example: access outside the approved window, access to unexpected hosts, anomalous authentication patterns), then route findings to response handling (PCI DSS v4.0.1 Requirement 8.2.7).

Plain-English requirement (quick test)

If an auditor asks, “Show me a third-party remote access account that was enabled for support, then disabled right after, and show me what monitoring would have alerted if it did something weird,” you should be able to answer with one ticket and a clean chain of evidence.

Who it applies to

Entities: Merchants, service providers, and payment processors that must comply with PCI DSS and allow third parties to remotely access, support, or maintain system components (PCI DSS v4.0.1 Requirement 8.2.7).

Operational context (where this shows up):

• Third-party IT support connecting to servers, POS support systems, virtualization hosts, network gear, or security tools.
• Software providers or MSPs using remote tools (VPN, bastion, remote management agents, SaaS admin consoles) to administer your environment.
• Break/fix manufacturers or integrators performing remote diagnostics on infrastructure.
• Cloud/platform third-party administrators who receive privileged access into management planes that can affect cardholder data environment boundaries.

Scope note you should document: This is about accounts used by third parties and remote access into system components. In practice, define “remote access” for your environment (VPN, ZTNA, bastion, remote support tooling, direct SaaS console access) and list approved methods.

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

1) Build a complete inventory of third-party remote access paths and accounts

• Enumerate remote access entry points: VPN concentrators, ZTNA, bastions/jump hosts, remote support tools, and admin consoles.
• Enumerate third-party identities: named user accounts, service accounts, break-glass accounts, tool-specific accounts.
• Map each account to: third party name, sponsoring system owner, access method, target systems, privilege level, and business purpose. Deliverable: “Third-party remote access register” (can be a spreadsheet, GRC record, or IAM inventory export).

2) Set the control rule: disabled by default + time-bound enablement

Implement a workflow where:

• Access is requested (ticket or change record).
• Access is approved by the system owner (and security if your model requires it).
• Account is enabled for a defined window and then disabled automatically or by a required post-task step.
• Any extension requires a new approval.

Practical patterns that satisfy the intent:

• Just-in-time (JIT) enablement: account disabled until approval triggers enablement.
• Time-bound group membership: add third-party user to an access group that expires.
• Temporary credentials: create short-lived credentials for the support event, then revoke.

Avoid “we disable them later” as a control statement. Auditors will look for timestamps that prove the disablement happened when the need ended (PCI DSS v4.0.1 Requirement 8.2.7).

3) Make “not in use” unambiguous

Define objective closure criteria. Examples you can adopt operationally:

• Ticket status changed to “Complete” plus a required “Disable access” task.
• Change window ends plus a verification step by the system owner.
• Automated expiry time reached plus a daily exception report for any account still enabled.

Your procedure should specify: who disables, how quickly it must happen after work ends, and what evidence proves it.

4) Instrument monitoring that can detect “unexpected activity”

Requirement 8.2.7 is not satisfied by passive log retention alone; you need monitoring that can reasonably surface unexpected use (PCI DSS v4.0.1 Requirement 8.2.7). Do this in layers:

Minimum monitoring coverage

• Authentication logs for the remote access method (VPN/ZTNA/bastion/SaaS).
• Session logs where available (bastion session recording, remote tool session logs).
• System logs on targeted assets for privileged actions when feasible.

Define “unexpected” in writing Create detection rules aligned to your workflow:

• Access outside the approved time window.
• Access from unusual source geographies or IP ranges (if you have a normal baseline).
• Attempts to access systems not in the approved ticket scope.
• Multiple failed logins or MFA failures followed by success.
• New device enrollment or new remote tool installation tied to third-party identities.

Operational response

• Route alerts to a queue with an owner (SOC, IT security, or on-call).
• Require a disposition: expected (tied to ticket) or unexpected (incident workflow).
• Keep evidence of triage decisions.

5) Assign ownership and make it repeatable

A workable RACI usually looks like:

• System owner: approves access window and scope; confirms task completion.
• IAM team: implements JIT enable/disable mechanics; maintains inventory.
• Security/SOC: owns monitoring rules and alert triage.
• Vendor/TPRM function: ensures contracts and third-party onboarding require named accounts and approved access methods.

If you’re using Daydream for third-party risk management, connect each third party record to (a) their approved remote access method, (b) the account inventory, and (c) the evidence bundle for each support event so audits don’t become a scavenger hunt.

Required evidence and artifacts to retain

Auditors typically want a traceable chain from request → enable → use → disable → monitor/alert review. Keep:

• Policy/standard: Third-party remote access standard stating disabled-by-default, time-bound enablement, and monitoring expectations (PCI DSS v4.0.1 Requirement 8.2.7).
• Procedure/runbook: Step-by-step enable/disable workflow with roles and approvals.
• Inventory/register: List of third-party remote access accounts and approved methods.
• Tickets/approvals: For sampled events, show request, scope, approval, and work window.
• System evidence: IAM logs showing enable/disable timestamps; VPN/ZTNA/bastion logs for access sessions.
• Monitoring evidence: SIEM detections or alert rules; alert queue records; triage notes.
• Exception handling: Documented exceptions, compensating controls, and management approval if applicable.

Common exam/audit questions and hangups

• “Show me all third-party accounts with remote access and prove they’re disabled when not in use.”
• “How do you ensure accounts are disabled after the support window ends?”
• “How do you monitor for unexpected activity? What would you alert on?”
• “Are any third-party accounts shared across multiple technicians?”
• “Can a third party access without a ticket? What prevents it?”
• “What’s the approved remote access method, and how do you block other paths?”

Hangups that trigger deeper testing:

• Standing VPN accounts for MSPs with no expiry.
• No linkage between a session and an approval record.
• Monitoring that is “logs are stored” with no defined alerting or review.

Frequent implementation mistakes (and fixes)

1. Mistake: leaving accounts enabled ‘just in case.’
   Fix: make enablement an explicit support step with auto-expiry; measure exceptions by reporting on enabled state outside approved windows (PCI DSS v4.0.1 Requirement 8.2.7).

2. Mistake: shared third-party credentials.
   Fix: require named accounts per technician; map each to the third party and contract.

3. Mistake: monitoring without context.
   Fix: enrich logs with account owner (third party), approved window (ticket), and target system list so “unexpected” is detectable.

4. Mistake: “disabled” means “password changed” or “VPN revoked,” but other paths remain.
   Fix: treat “remote access account” broadly; close all entry points for that identity and method.

5. Mistake: no owner for deprovisioning.
   Fix: assign the system owner accountability; IAM executes; security verifies via exception reports.

Risk implications (why auditors care)

Third-party remote access is a common path for unauthorized access because it often bypasses your normal endpoint controls and may involve elevated privileges. Requirement 8.2.7 forces you to reduce the time window attackers can exploit and increase the chance of detecting misuse through monitoring (PCI DSS v4.0.1 Requirement 8.2.7).

Practical execution plan (30/60/90)

First 30 days (stabilize and stop the bleeding)

• Identify all third-party remote access methods and accounts; build a single inventory.
• Disable any clearly unused accounts and document the decision.
• Require a ticket to enable access for new support events.
• Turn on logging for the access path and route it to your monitoring platform.

Days 31–60 (implement time-bounded enable/disable)

• Implement JIT enablement or expiring group membership for the primary remote access method.
• Standardize the approval template: third party, named account, systems, work window, change/ticket ID.
• Create an exception report: third-party remote access accounts currently enabled, with last-used time.

Days 61–90 (make monitoring defensible)

• Define “unexpected activity” rules tied to your workflow (outside window, unexpected systems, anomalous auth).
• Add alert triage steps and require documented dispositions.
• Run a tabletop test using a sample third-party session: verify you can reconstruct the full chain of evidence quickly.

Frequently Asked Questions

Do we have to disable third-party accounts even if the contract is active year-round?

Yes. The requirement is about the access account state, not the contract term: enable only during the time needed and disable when not in use (PCI DSS v4.0.1 Requirement 8.2.7). Use JIT enablement so operational support stays fast without leaving standing access.

What counts as “remote access” for this requirement?

Treat any non-local access path used by a third party to reach system components as remote access, including VPN, ZTNA, bastions, remote support tools, and cloud/SaaS admin consoles. Document your definition and the approved methods so audits and operations align.

Is log collection enough to meet “use is monitored for unexpected activity”?

Monitoring implies you can detect and respond to unexpected activity, not just store logs (PCI DSS v4.0.1 Requirement 8.2.7). Implement alerting and a review/triage workflow tied to third-party identities and support windows.

How do we handle emergency access when we can’t wait for approvals?

Pre-define an emergency workflow with a fast approver, a short enablement window, and required after-action review. Keep the same evidence chain: who approved, when it was enabled, what happened during the session, and when it was disabled.

What if the third party insists on using their remote management tool?

Treat it as an access method decision: either approve it with equivalent controls (time-bounded access and monitoring) or require your controlled access path. If you approve it, ensure you can log sessions and tie them to named accounts and tickets.

How do we prove accounts are disabled “when not in use” during an audit?

Provide an account inventory plus system evidence showing disablement timestamps and an exception report for any enabled accounts outside an approved window. Pair that with sampled tickets that show the enable/disable workflow end-to-end.