SC-8: Transmission Confidentiality and Integrity

Quick-reference card

What this control requires

SC-08 requires organizations to protect both the confidentiality and integrity of information while it moves between systems, networks, and devices. That obligation extends beyond the network perimeter to every component capable of transmitting data, including servers, laptops, mobile devices, printers, scanners, and even fax machines.

In practice, this control means you can’t treat any communication path as inherently trusted. Unprotected transmissions are vulnerable to interception and modification, whether they cross the public internet or travel between systems on your internal network. Organizations satisfy SC-08 through physical protections such as protected distribution systems (PDS) or through logical protections such as cryptographic protocols.

The control also recognizes operational reality. Organizations that rely on commercial telecommunications providers for transmission services may not have access to dedicated, physically isolated channels. In those cases, compensating controls become necessary to achieve equivalent protection for data in transit.

Why it matters

Most organizations invest heavily in perimeter defenses and encryption at rest, then assume their internal networks are trusted zones. That assumption creates a gap that attackers actively exploit. When data travels unprotected between internal systems, anyone who gains a foothold on the network can intercept credentials, financial records, and personally identifiable information without triggering a single alert.

The consequences of failing to protect data in transit extend beyond data theft. Attackers who can modify transmitted information can alter transaction records, inject malicious payloads, or redirect communications. These integrity violations are harder to detect than confidentiality breaches and can persist for months before discovery.

Heartland Payment Systems Breach

In late 2007, Albert Gonzalez and two Russian co-conspirators compromised Heartland Payment Systems, one of the largest payment processors in the United States, through SQL injection against a web application. Heartland had implemented encryption for card data at rest, but the internal payment processing network carried transaction data, including Track 1 and Track 2 magnetic stripe data, in plaintext between systems. The organization assumed its internal network was a trusted zone.

The attackers installed a packet sniffer on the internal network that captured card data in the clear as it traversed the wire. That sniffer operated undetected for approximately 14 months before the breach was discovered in January 2009. The SC-08 failure was the gap between perimeter security and transmission security on internal networks. Heartland had invested in encryption at the boundary but had not applied cryptographic protection to data in transit within the internal environment.

Approximately 134 million credit and debit card numbers were exposed. Heartland paid over $145 million in compensation to card issuers, and Albert Gonzalez was sentenced to 20 years in federal prison.

What attackers exploit

• Unencrypted internal network segments where sensitive data moves between application tiers, databases, and processing systems in plaintext
• Wireless access points that transmit credentials and session tokens without transport layer security (TLS) or equivalent encryption
• Legacy protocols such as FTP, Telnet, and unencrypted SMTP that remain active in production environments
• Man-in-the-middle positions on network segments that lack mutual authentication between endpoints
• Remote maintenance channels that bypass encryption and access controls, allowing session hijacking or credential interception

How to implement

The core challenge with SC-08 is scope. Protecting data in transit isn’t a single configuration change; it requires coordinated controls across network architecture, application design, device management, and monitoring. Organizations often address external-facing encryption first and then struggle to extend the same rigor to internal communications.

For your organization

Start with a data flow inventory that maps every path sensitive information takes across your environment. Identify where data moves between systems, between network segments, and between physical locations. This inventory becomes the foundation for determining which transmission paths need cryptographic protection and which can rely on physical controls.

Implement TLS 1.2 or higher for all internal and external communications. Retire legacy protocols that don’t support encryption, including unencrypted FTP, Telnet, and HTTP. Where legacy systems can’t support modern cryptographic protocols, isolate them on dedicated network segments with compensating controls such as network monitoring and strict access restrictions.

Deploy mutual authentication on critical internal communication paths. Standard TLS validates the server to the client, but mutual TLS (mTLS) requires both endpoints to present certificates, which prevents man-in-the-middle attacks even if an attacker gains network access. Prioritize mTLS for communications between application tiers, database connections, and API endpoints that handle sensitive data.

Configure protected distribution systems for physical transmission paths where logical encryption isn’t feasible. PDS uses physically protected cabling, conduits, and enclosures to prevent unauthorized access to the transmission medium. This approach is common in classified environments but also applies to any facility where physical interception is a credible threat.

Establish continuous monitoring for unencrypted traffic on your network. Deploy network detection tools that alert when sensitive data traverses the wire without encryption, and integrate those alerts into your security information and event management (SIEM) platform. Periodic scans alone won’t catch misconfigurations or regressions that re-introduce plaintext transmission paths.

For your vendors

Request evidence that vendors encrypt all data transmissions involving your organization’s information. The vendor’s system and communications protection policy should explicitly address transmission confidentiality and integrity requirements, not just data-at-rest encryption.

Ask vendors to provide their TLS configuration documentation, including supported protocol versions, cipher suites, and certificate management practices. Red flags include support for TLS 1.0 or 1.1, use of weak cipher suites such as RC4 or DES, and expired or self-signed certificates on production systems. These configurations indicate the vendor hasn’t kept pace with current cryptographic standards.

Verify that vendors apply encryption to internal data flows, not just at the perimeter. The Heartland breach demonstrated that perimeter-only encryption leaves internal transmission paths exposed. Request network architecture diagrams that show where encryption terminates and whether sensitive data travels in plaintext between internal systems.

Review the vendor’s approach to remote access and maintenance channels. Nonlocal maintenance sessions should use encrypted connections with multi-factor authentication. Ask for documentation of how remote sessions are logged, monitored, and terminated after inactivity.

Include transmission security requirements in your vendor contracts and service-level agreements. Specify minimum TLS versions, required cipher suites, and incident notification timelines for any breach of transmission security controls. Conduct periodic re-assessments to confirm that vendors maintain their encryption posture as their infrastructure evolves.

Evidence examples

Cross-framework mapping

Related controls

• AC-17 — Remote Access: remote access sessions transmit data across external networks, making SC-08 encryption requirements a prerequisite for protecting those connections.
• AC-18 — Wireless Access: wireless networks broadcast data over radio frequencies, requiring SC-08 transmission protections to prevent interception of over-the-air communications.
• AU-10 — Non-repudiation: integrity protections under SC-08 support non-repudiation by ensuring transmitted records haven’t been altered between sender and receiver.
• IA-03 — Device Identification and Authentication: authenticating devices before allowing network communication complements SC-08 by ensuring encrypted channels connect to verified endpoints.
• IA-08 — Identification and Authentication (Non-organizational Users): external users accessing organizational systems require both authenticated sessions and encrypted transmission channels to protect credentials and data.
• IA-09 — Service Identification and Authentication: service-to-service authentication works alongside SC-08 to ensure that encrypted communications occur between verified services rather than impersonated endpoints.
• MA-04 — Nonlocal Maintenance: remote maintenance sessions carry privileged commands and diagnostic data, requiring SC-08 encryption to protect those transmissions from interception.
• PE-04 — Access Control for Transmission: physical protection of transmission media through conduits, enclosures, and controlled spaces complements the logical encryption that SC-08 requires.
• SA-04 — Acquisition Process: procurement specifications should include SC-08 transmission security requirements so that acquired systems support encryption and integrity protections from deployment.
• SA-08 — Security and Privacy Engineering Principles: engineering systems with encryption-by-default and zero-trust network assumptions builds SC-08 compliance into the architecture rather than adding it as an afterthought.

Frequently asked questions

What is NIST SP 800-53 SC-08?

SC-08 is the NIST SP 800-53 control that requires organizations to protect the confidentiality and integrity of transmitted information across all communication paths. It applies to every system component capable of sending or receiving data, including servers, workstations, mobile devices, and peripheral equipment like printers and scanners. Organizations meet SC-08 through cryptographic protections such as TLS or through physical measures such as protected distribution systems. The control is included in both the Moderate and High baselines.

What happens if SC-08 is not implemented?

Without SC-08 controls, data traveling between systems is exposed to interception and modification by anyone with access to the network path. Attackers can capture sensitive information such as credentials, payment data, and personally identifiable information using packet sniffers on unprotected network segments. The Heartland Payment Systems breach demonstrated that even organizations with perimeter encryption can lose over 134 million records when internal transmission paths lack cryptographic protection. Regulatory consequences include audit findings, potential fines, and loss of authorization to operate.

How do you audit SC-08?

Auditing SC-08 starts with reviewing the system and communications protection policy and the procedures addressing transmission confidentiality and integrity to confirm they define encryption requirements for all data paths. Assessors then examine system configuration settings to verify that TLS 1.2 or higher is enforced, weak cipher suites are disabled, and certificates are current. Network scans and system audit records provide evidence that unencrypted transmission paths don’t exist in production. Protected distribution systems, where used, require physical inspection of cabling, conduits, and enclosures.

What is the difference between SC-08 and SC-28?

SC-08 protects data in transit, while SC-28 protects data at rest. SC-08 addresses the confidentiality and integrity of information as it moves between systems, networks, and devices through encryption protocols such as TLS. SC-28 covers information stored on disk, in databases, or on removable media through mechanisms such as full-disk encryption and database-level encryption. Both controls are necessary because protecting data at only one stage leaves it exposed at the other.