Protect account data with strong cryptography during transmission

To meet the protect account data with strong cryptography during transmission requirement in PCI DSS 4.0, you must ensure that any payment account data sent across open or untrusted networks is protected with strong cryptography and that your encryption and certificate controls are provably enforced in production ¹. Operationalize it by inventorying in-scope data flows, enforcing TLS-based transport encryption, and retaining audit-ready evidence.

Key takeaways:

• Encrypt any in-scope account data in transit across open/untrusted networks with strong cryptography ¹.
• “Configured” is not enough; you need evidence that encryption is enforced and monitored in real environments.
• Certificate governance (issuance, renewal, revocation, and scanning) is part of making transport encryption audit-proof.

This requirement is simple to say and easy to fail in practice: if account data crosses an open or untrusted network, it must be protected by strong cryptography ¹. The common failure mode is scope blind spots. Teams encrypt the obvious web checkout path, but miss internal “side doors” like batch file transfers, admin portals, partner connections, legacy APIs, service-to-service calls, or email/chat workflows that move account data.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this control is to treat it like a data-flow enforcement problem plus an evidence problem. You need (1) a defensible map of where account data travels, (2) technical guardrails that make insecure transport hard or impossible, and (3) durable artifacts that prove your guardrails are working.

This page translates the PCI DSS 4.0 requirement into implementation steps you can assign to engineering and security teams immediately, plus the evidence you should collect for assessment. It also calls out exam hangups and mistakes that repeatedly show up during PCI reviews.

Regulatory text

PCI DSS 4.0 (PCI-09) excerpt: “Protect account data in transit across open or untrusted networks.” ¹

What the operator must do:
You must ensure that when payment account data is transmitted over networks you do not fully trust (including the public internet and any other network segment treated as untrusted), the transmission is protected by strong cryptography ¹. Operationally, that means you need enforced, verified transport encryption for in-scope protocols and interfaces, plus governance over certificates/keys that underpin that encryption.

Plain-English interpretation

If cardholder data or related account data leaves a system boundary and crosses a network where interception is plausible, you must encrypt it in transit using modern cryptography ¹. Assessors will look for two things:

1. Coverage: Did you find all the places account data is transmitted?
2. Enforcement and proof: Do systems reject weak or plaintext connections, and can you show configuration and testing evidence?

Who it applies to (entity and operational context)

Applies to: Merchants and service providers that store, process, or transmit account data ¹.

Operational contexts where this usually becomes “in scope”:

• Browser/app to web servers that accept payments.
• API traffic between front-end, payment services, and downstream processors.
• Remote administration paths into the cardholder data environment (CDE) or connected systems.
• Third-party connections (payment gateways, call centers, fraud tooling, customer support platforms) where account data is exchanged.
• File transfers, batch exports, reporting feeds, or integrations moving account data to other systems.

What counts as “open or untrusted”:

• The public internet is the obvious case.
• Any partner network, user network, or shared network segment you treat as untrusted by design should be treated similarly.
• If you can’t clearly justify the trust boundary, treat it as untrusted and encrypt.

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

Step 1: Inventory and classify transmissions of account data

Create a data-in-transit inventory for account data. Make it assessment-ready.

• List each transmission path: source system, destination system, protocol, port, authentication method, and whether it crosses an untrusted boundary.
• Include human workflows (support uploads, email exports) and machine workflows (APIs, ETL jobs, queues).
• Record ownership: one business owner and one technical owner per data flow.

Output: “Account Data Transmission Register” tied to your PCI scope narrative ¹.

Step 2: Define the required cryptographic transport standard

Write a short, enforceable engineering standard that answers:

• Approved transport protocols for in-scope transmissions (for most orgs, this is TLS-based transport).
• Minimum acceptable protocol versions and cryptographic parameters (keep this as a policy requirement; implement specifics in configuration baselines so teams can patch without rewriting policy).
• Prohibited protocols (plaintext and weakly protected transports) for account data over untrusted networks ¹.

Practical tip: Put “deny by default” language in the standard: systems must refuse insecure negotiation rather than “support both.”

Step 3: Enforce encryption at the edge and between services

Implement controls that make compliance the default:

• External ingress: Terminate or pass through TLS at load balancers, API gateways, and WAFs with hardened configurations.
• Internal service-to-service: Require TLS for service calls that traverse untrusted segments or where segmentation is not provably strong.
• Admin access: Require encrypted channels for remote access into in-scope systems ¹.

Guardrails that auditors like because they show enforcement:

• Configuration-as-code baselines for gateways/proxies that disable weak protocols.
• Network controls that block plaintext protocols for in-scope paths.
• Centralized service mesh or mTLS where appropriate, with policy preventing non-TLS traffic.

Step 4: Implement certificate governance (make TLS sustainable)

Transport encryption fails quietly when certificates expire or are mis-issued. Build basic governance:

• Certificate issuance process: approved CAs, approval workflow, and ownership.
• Inventory of certificates used for in-scope services.
• Monitoring for expiration and misconfiguration.
• Rotation/renewal procedures and emergency replacement steps.

This directly supports the recommended control: transport encryption and certificate governance requirements ¹.

Step 5: Validate with testing that mirrors real attacker paths

Run validation that proves the requirement is met:

• Attempt plaintext connections where account data could flow; confirm rejection.
• Scan endpoints for supported protocols/ciphers and confirm they match your standard.
• Confirm third-party integrations use encrypted transport for account data transmissions.

Treat test results as evidence, not just engineering hygiene ¹.

Step 6: Monitor and respond

Add ongoing signals:

• Alerts for certificate expiration, handshake failures (that indicate fallback behavior), and misconfigured endpoints.
• Periodic review of the data-flow register when new apps, integrations, or networks are introduced.
• Change management hooks: any new integration that transmits account data must document its encryption approach before go-live ¹.

Required evidence and artifacts to retain

Keep artifacts that show design + operation:

Policy/standards

• Transport encryption standard for account data in transit, including prohibited protocols ¹.
• Certificate management standard and ownership model.

Scope and data-flow proof

• Account Data Transmission Register with trust boundary classification.
• Diagrams showing untrusted networks and encryption points.

Technical configuration evidence

• TLS configuration snippets for gateways, load balancers, web servers, and API endpoints.
• Screenshots/exports from configuration management showing enforced settings.

Validation evidence

• Endpoint scan outputs (protocol/cipher support results) for in-scope entry points.
• Test records showing plaintext connections are blocked or redirected without exposing account data.
• Evidence from third-party integration testing or contractual requirements that transmissions are encrypted.

Operational evidence

• Certificate inventory and renewal records.
• Monitoring/alerting configuration and sample alerts or tickets demonstrating response.

If you use Daydream to manage compliance operations, treat these artifacts as first-class objects: map each data flow and system endpoint to the requirement, attach configuration and scan outputs, and keep an assessor-ready evidence trail that survives team turnover.

Common exam/audit questions and hangups

Expect assessors to probe these areas ¹:

• “Show me all transmission paths for account data across untrusted networks.”
• “How do you know TLS is enforced and not optional?”
• “What prevents a service from falling back to plaintext or weak negotiation?”
• “How do you manage certificates and prevent expiration outages?”
• “How do you handle third-party connections and confirm encryption?”

Hangup that derails reviews: Teams can describe the intent (“we use HTTPS”) but cannot produce a complete data-flow inventory or hard proof from production configurations and tests.

Frequent implementation mistakes and how to avoid them

1. Encrypting only customer-facing traffic.
   Fix: Build the transmission register and include backend, batch, and third-party feeds.

2. Allowing weak fallback for “compatibility.”
   Fix: Enforce strict TLS configurations on gateways and servers; document exception handling with compensating controls.

3. Treating certificate renewal as a calendar reminder.
   Fix: Centralize certificate inventory and automate monitoring and renewal workflows.

4. Assuming a private network is “trusted” without evidence.
   Fix: Tie “trusted” claims to segmentation design and verification; otherwise encrypt.

5. Evidence sprawl.
   Fix: Standardize evidence collection (scan outputs, configs, tickets) and store it in a system of record aligned to PCI requirements.

Enforcement context and risk implications

The requirement targets a straightforward risk: interception or manipulation of account data in transit across networks that attackers can observe or influence ¹. Even without a cited enforcement case in the provided sources, PCI assessments routinely treat in-transit protection as a high-visibility control because failures are externally exploitable and easy to verify with scanning and traffic observation.

30/60/90-day execution plan

First 30 days: establish scope, standards, and quick wins

• Build the first version of the Account Data Transmission Register and get system owners to sign off.
• Publish a transport encryption and certificate governance standard (engineering-readable).
• Identify and remediate obvious plaintext paths (file transfers, legacy endpoints, admin interfaces) where account data might traverse untrusted networks.
• Stand up basic certificate inventory and expiration monitoring for in-scope endpoints.

By 60 days: enforce and prove

• Enforce TLS configurations at all ingress points for in-scope applications.
• Implement controls that prevent plaintext for known in-scope flows (gateway policy, firewall rules, service configuration baselines).
• Run validation scans/tests and store results as evidence.
• Add change-management checkpoints for new integrations transmitting account data.

By 90 days: operationalize and harden

• Expand enforcement to service-to-service paths where trust boundaries are unclear or evolving.
• Formalize exception handling: documented risk acceptance, compensating controls, and remediation timelines.
• Implement recurring monitoring and review: certificate health, endpoint scanning cadence, and register updates tied to SDLC and vendor onboarding.
• Assemble an assessor packet in Daydream (or your GRC) that links each in-scope data flow to configs + validation evidence.

Frequently Asked Questions

Does “account data” here only mean PAN, or does it include other payment data?

Treat the requirement as applying to any account data transmissions that are in your PCI scope narrative and handled under PCI DSS ¹. If a data element can be used to facilitate payment fraud when intercepted, encrypt it in transit across untrusted networks.

If traffic stays inside our cloud VPC/VNet, is that an “untrusted network”?

PCI focuses on “open or untrusted networks” ¹. If you cannot clearly justify the network as trusted with segmentation and access controls, encrypt anyway; it is simpler to defend in an assessment.

Is HTTPS everywhere enough to pass this requirement?

Only if you can prove that HTTPS/TLS is enforced for all in-scope transmission paths and weak negotiation is disabled ¹. Assessors often ask for endpoint test results and configuration evidence, not just architecture statements.

What evidence is most persuasive to an assessor?

A complete transmission register plus technical proof: TLS configs from production entry points and scan/test outputs showing only approved encrypted transport is accepted ¹. Pair that with certificate inventory and renewal monitoring.

How do we handle third-party integrations where we don’t control the other side?

Make encryption a contractual and technical requirement for any third party that receives account data over untrusted networks ¹. Validate by testing the integration endpoints and retaining evidence of encryption requirements and verification.

What should we do if a legacy system cannot support modern encrypted transport?

Document it as an exception with defined compensating controls and a remediation plan aligned to PCI expectations ¹. Reduce exposure by isolating the flow, minimizing transmitted account data, and putting an encrypting proxy or gateway in front where feasible.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. PCI DSS v4.0