PCI DSS Remote Access: Sections 8 & 12 Explained

You need to run remote support into systems that touch cardholder data and show an auditor you met PCI DSS. That usually means proving who connected, that they were authorized, that multi‑factor auth and least privilege were used, and that the session and its scope were logged and approved. This article quotes the relevant PCI DSS requirement titles, explains what they mean for a typical support session, and gives a practical controls checklist you can present to an auditor.

Quoted requirement titles (the short pulls)

Here are the exact, single‑line requirement titles from PCI DSS v4.0 we’ll use as the anchor for the rest of the article:

• "Requirement 8: Identify users and authenticate access to system components."
• "Requirement 12: Maintain a policy that addresses information security for employees and contractors."

Those titles are the short, official lines. Both requirement sets have many sub‑requirements; below I translate the parts of 8 and 12 that actually bite when a vendor or support technician connects remotely.

What Requirement 8 demands for a remote support session

Requirement 8 is about identity and authentication. For a remote support session the practical implications are:

• Unique, attributable accounts only — no shared logins. Every technician who touches a system must use an individual, auditable account. If you let a vendor use a shared account to do support, you fail Requirement 8.
• Strong authentication and MFA where appropriate. PCI requires multi‑factor authentication for access to the cardholder data environment (CDE) from external networks or for administrative access. In practice that means the support technician must authenticate with a password plus a second factor (TOTP, push, or hardware token) before the support tool opens a session into CDE systems.
• Time‑limited and least‑privilege access. Accounts or authorizations used for vendor support must be scoped to only the systems and commands needed, and should be temporary — created or enabled only for the window of the work and revoked immediately after.
• Approved access flows and session initiation records. The organization should have a documented, auditable approval step (an emailed approval or ticket with manager/vendor sign‑off) that ties the session to a business justification and an owner.
• Credential handling rules. Shared or hard‑coded credentials must not be embedded in scripts; secrets used by support personnel should be issued or vaulted per your credential policy and rotated when an engagement ends.

Put another way: Requirement 8 turns the question "who connected and how were they authenticated?" into a set of binary checks — unique ID, MFA (where required), and an access window — that you must show an auditor.

What Requirement 12 demands for a remote support session

Requirement 12 forces organizations to codify how they manage security, including third‑party and remote access. For support sessions the parts that matter are:

• Documented remote‑access policies and procedures. You must have a written policy that defines approved remote access methods, the approval workflow, required authentication controls, and evidence retention expectations for vendor access.
• Third‑party/vendor management controls. Contracts or Statements of Work must specify security obligations for any vendor who will access CDE systems: acceptable tools, authentication methods, incident reporting SLAs, and audit log retention.
• Access approvals and periodic review. The policy must require that vendor access is approved by an authorized owner and that access rights are periodically reviewed and revoked if no longer required.
• Incident response and forensic readiness. If a support session leads to suspicious activity, your IR plan must cover how to preserve session logs, recordings, and relevant artifacts so investigators can reconstruct the event.
• Training and awareness. Personnel who grant or monitor vendor sessions must be trained on the policy and on how to validate a vendor's identity and scope of work.

Requirement 12 is essentially about governance: written rules, accepted tools, contractual obligations, and a repeatable approval + auditing process. An auditor will want to see the policy and evidence that it was followed.

Concrete checklist: an auditor‑friendly remote support session

Below is a practical checklist you can follow for each remote support session touching the CDE. Keep the artifacts together in the ticket or the change record — that's what auditors expect to review.

• Authorization artifact: a ticket, signed email, or change approval that names the requester, approver, scope, and business justification before the session starts.
• User identity proof: the technician’s unique account name and an authentication timestamp showing successful MFA. Screenshots or logs showing the MFA success are acceptable evidence.
• Time window and scope: start and end timestamps for the session; list of target hosts and the specific work performed (commands run or files changed).
• Least privilege enforcement: proof the account used had only the privileges required (role membership or privilege snapshot) or that elevation was explicitly granted and time‑boxed.
• Session recording and audit log: connection logs (source IP, destination host, client version), an audit trail of actions, and, where your policy requires, a session recording or keystroke log. Put these in a tamper‑resistant store.
• Credential change and rotation: if vendor access required shared credentials or privileged passwords, rotate them immediately after the engagement and record the rotation event.
• Post‑session review: a manager or system owner verifies that the work was completed and attests that no unexpected changes occurred; a short post‑support note added to the ticket is ideal.
• Retention note: store the authorization, logs, and recordings per your retention policy (see your PCI policy). Make them searchable by ticket or asset identifier so an auditor can reconstruct the session in minutes, not weeks.

That checklist answers both Requirement 8 (who authenticated and how) and Requirement 12 (was there an approved, documented process and contractual cover?).

Where the relay or cloud service fits — Tenvo’s positioning

If your support tool uses a relay — either a vendor‑run relay or your own — you must understand two hard facts. First, direct peer‑to‑peer connections are end‑to‑end between the two endpoints. Second, when traffic falls back to a relay the TLS connection terminates at the relay, so whoever operates that relay can technically access session traffic. That is a reality for any managed relay-based remote desktop service; you should not say the relay "cannot decrypt" unless you operate the relay and control keys yourself.

At Tenvo we recommend our managed multi‑region relay as the default for most customers because it reduces operational work: there’s no on‑call for relay servers, no certificate renewal burden, and Tenvo provides native clients for Windows, macOS and Linux plus a browser client in public beta. Our pricing tiers are Free $0, Lite $2.99/mo, and Pro $7.99/mo. Use the managed relay unless you have a written compliance requirement that forbids third‑party infrastructure. If such a written requirement exists — data residency mandates, an isolated air‑gapped network, or a contract clause that forbids third‑party hosting — self‑hosting is the correct choice, but it comes with the maintenance costs the auditor will expect you to prove.

If you choose Tenvo’s managed relay, document that choice in your vendor management artifacts and add the relay operator to the list of parties in your third‑party contract language. That transparency is what auditors look for under Requirement 12.

Sample evidence pack (what to hand the auditor)

When an auditor asks for proof of a support session, give them a single zipped folder (or a ticket with links) containing:

• Policy excerpt: the remote‑access policy clause that defines approvals, MFA, and logging (Requirement 12 evidence).
• Approval artifact: the ticket or signed change approval referenced in the checklist above.
• Authentication logs: a single export showing the technician’s unique ID, the MFA event, and timestamps (Requirement 8 evidence).
• Session logs and recording: connection log, actions log, and the session recording if your policy requires it (or the reason why recording wasn’t used, with compensating controls).
• Privilege snapshot: the role or ACL that applied to the technician’s account during the session and a statement that access was time‑limited.
• Contract language: vendor agreement or SOW that sets security requirements and incident reporting obligations (Requirement 12 evidence).
• Post‑session attestation: manager or asset owner confirmation that the work completed matched the scope and that credentials were rotated if needed.

Give these artifacts with clear filenames and a short index document that maps each file to the checklist items — auditors appreciate the time savings.

Common pitfalls and auditor triggers

These are mistakes we regularly see that instantly extend an auditor’s engagement:

• Shared accounts. If several technicians use the same login, you can’t attribute actions and the auditor will fail you on Requirement 8.
• No MFA for external access. If the technician authenticates from an external network and MFA wasn’t used to enter the CDE, that’s a clear finding.
• Missing pre‑approval. Allowing spontaneous, post‑facto approvals ("we let them in and then documented it") fails Requirement 12 expectations for documented process.
• No logs or incomplete timestamps. Logs with gaps, inconsistent clocks, or missing start/end markers will force the auditor to request more evidence.
• Untracked use of vendor tools. If a vendor connects with a tool not listed in your policy and not covered in the contract, the auditor will escalate vendor management questions.

Fix these before your assessment: eliminate shared accounts, require MFA for every remote connection into the CDE, formalize pre‑approved vendor windows, and centralize log collection.

When to self‑host a relay — and why it’s not the default

Self‑hosting your relay (or using an on‑prem broker) is valid when you have a formal constraint: written compliance language forbids third‑party infrastructure; you operate in an isolated network; or a data‑residency law forces you to keep relays inside a region you control. If you self‑host, the auditor will expect you to prove you operate the relay securely: patching cadence, certificate lifecycle, high‑availability, backup, and an incident response plan that includes the relay.

For most organizations, a managed relay costs less overall once you count on‑call time, patching, key custody, certificate renewal, and the single‑region risk without failover. Tenvo’s managed relay reduces that operational overhead — but document the choice and include the relay operator in your third‑party controls.

Further reading and related guides

If you need practical how‑tos and configuration references, start with these Tenvo articles: Remote Desktop Audit Logging for log formats and retention; How to Give Someone Remote Access for safe session workflows; and Remote Desktop Security: What You Need to Know for the overall threat model and MFA options.

These will help you build the artifacts auditors expect and the operational habits your security team needs.

Bottom line and next steps

PCI DSS Requirement 8 forces you to prove identity, MFA and least privilege for every support session. Requirement 12 forces you to have a written, enforced policy that governs those sessions and your vendors. Combine an enforced approval workflow, individual accounts with MFA, time‑boxed privilege, session logging/recording, and contractual vendor controls, and you’ll cover the parts auditors focus on for remote support.

If you want a practical starting point: document your approval flow, require unique accounts + MFA for all remote access to CDE systems, centralize session logs in a tamper‑resistant store, and record an attestation after every session. Use a managed relay like Tenvo for lower operational overhead unless a written rule forces you to self‑host.

Download Tenvo to test a compliant workflow: Download.