SC-13: Cryptographic Protection

Quick-reference card

What this control requires

SC-13 requires organizations to identify every use of cryptography across their systems and then implement the specific type of cryptographic protection each use demands. That means you can’t treat encryption as a blanket checkbox. You need to map where cryptography is applied, why it’s applied, and which standard governs each instance.

In practice, the control breaks into two actions. First, you define the cryptographic uses: protecting data at rest, securing data in transit, generating digital signatures, enforcing information separation, producing hash values, or generating random numbers. Second, you match each use to the appropriate cryptographic standard. Federal systems typically require FIPS-validated cryptography for unclassified data and NSA-approved cryptography for classified data. The distinction matters because applying the wrong standard to a given use case can leave data exposed even when encryption is technically in place.

The requirement exists because cryptography underpins nearly every trust decision in a modern system. Authentication tokens, TLS sessions, code-signing certificates, and encrypted storage volumes all depend on correctly implemented cryptographic mechanisms. When those mechanisms are absent, misconfigured, or based on deprecated algorithms, the entire security architecture weakens from the inside out.

Why it matters

Most organizations encrypt something, but few maintain a complete inventory of where and how cryptography is used across their environment. That gap between partial adoption and systematic implementation is exactly where SC-13 failures occur. A single unprotected channel, an overlooked signing key, or a deprecated algorithm running on a legacy system can undermine cryptographic protections that are otherwise well implemented.

The consequences extend beyond data exposure. Weak or missing cryptographic controls erode the trust models that systems rely on to verify identities, validate software integrity, and enforce access boundaries. When a certificate authority is compromised, when a hash function is broken, or when a signing key is stolen, the downstream effects cascade across every system that trusted that cryptographic mechanism.

Bit9 Code-Signing Certificate Breach

In February 2013, security company Bit9 disclosed that attackers had breached its corporate network and accessed a server containing its private code-signing certificate. Bit9’s application whitelisting product was used to protect networks at U.S. government agencies and over 30 Fortune 100 companies, making its signing infrastructure a high-value target. The attackers used the stolen certificate to digitally sign malware, which was then deployed against at least three of Bit9’s own customers. Bit9’s CEO acknowledged the root cause: the company had failed to install its own endpoint security product on the compromised server.

A code-signing certificate is a cryptographic mechanism that establishes trust. Software bearing a valid signature from a trusted issuer is treated as legitimate by operating systems and security tools. When the private key behind those signatures isn’t adequately protected, the entire trust model collapses. An attacker who possesses a signing key can produce malware that is indistinguishable from legitimate software to any system that trusts that certificate. Krebs on Security compared the attack to the 2011 RSA SecurID breach, another case of attackers targeting a security vendor’s cryptographic infrastructure to enable downstream attacks on that vendor’s customers.

Specifically, the Bit9 breach illustrates what happens when SC-13 fails at the infrastructure level. The signing key was stored on a server that wasn’t isolated, wasn’t monitored, and wasn’t running the very product Bit9 sold to its clients.

What attackers exploit

• Unprotected cryptographic key material stored on systems without adequate access controls or monitoring
• Deprecated or non-FIPS-validated cryptographic algorithms that are vulnerable to known attacks
• Missing cryptographic protections on internal channels that organizations assume are “safe” because they sit behind a perimeter
• Code-signing infrastructure that lacks the same security rigor applied to production environments
• Gaps between cryptographic policy and actual implementation, where documentation says encryption is in place but operational systems don’t enforce it

How to implement

The most common SC-13 failure isn’t the absence of cryptography. It’s the absence of a comprehensive inventory that maps each cryptographic use to a validated implementation. Organizations encrypt data in transit with TLS but forget to account for database encryption at rest, inter-service communication within a cloud VPC, or the cryptographic modules backing their digital signature workflows.

For your organization

1. Build a cryptographic use inventory

Start by cataloging every system, application, and data flow where cryptography is used or should be used. Include encryption at rest, encryption in transit, digital signatures, hashing, random number generation, and certificate-based authentication. Document the specific cryptographic algorithm and module for each use.

2. Validate FIPS compliance for each module

Verify that every cryptographic module in use appears on the NIST Cryptographic Module Validation Program (CMVP) validated modules list. For each module, confirm the validation certificate number, the operational environment it’s approved for, and whether it’s running in a FIPS 140-2 approved mode. Non-validated modules need to be flagged for replacement.

3. Enforce key management controls

Cryptographic protection is only as strong as the keys behind it. Implement documented procedures for key generation, distribution, storage, rotation, and destruction. Ensure private keys are stored in hardware security modules (HSMs) or equivalent tamper-resistant environments, not on general-purpose servers.

4. Monitor and audit cryptographic configurations

Deploy automated scanning to detect deprecated algorithms (such as SHA-1, DES, or RC4), expired certificates, and non-compliant TLS configurations. Integrate cryptographic compliance checks into your continuous monitoring program so that configuration drift doesn’t silently degrade your posture.

5. Align policy with implementation

Your system and communications protection policy should specify which cryptographic standards apply to each data classification level. Conduct periodic reviews to confirm that operational configurations match documented policy, especially after system upgrades, migrations, or vendor changes.

For your vendors

1. Request cryptographic compliance documentation

Ask vendors to provide their cryptographic use inventory, including which algorithms and modules protect your data in transit and at rest. Request FIPS 140-2 or FIPS 140-3 validation certificate numbers for each module.

2. Evaluate key management practices

Include questions about key generation, storage, rotation, and destruction in your vendor security assessments. Pay particular attention to whether vendors store cryptographic keys in HSMs, how they handle key compromise events, and whether they maintain separation between key management and data processing environments.

3. Watch for red flags

Non-FIPS-validated modules, self-signed certificates in production, or the use of deprecated algorithms (MD5, SHA-1, DES) are indicators that a vendor hasn’t implemented SC-13 adequately. Vendors who can’t articulate their cryptographic standards or provide validation certificates warrant deeper scrutiny.

4. Verify through evidence

Don’t rely solely on questionnaire responses. Request SOC 2 reports, penetration test summaries covering cryptographic controls, and configuration documentation for systems handling your data. Third-party attestations from qualified auditors provide stronger assurance than self-reported answers.

Evidence examples

Cross-framework mapping

Related controls

• AC-02 — Account Management: account lifecycle controls determine who has access to systems where cryptographic material is stored and managed.
• AC-03 — Access Enforcement: access enforcement mechanisms protect cryptographic keys and modules from unauthorized use or extraction.
• AC-07 — Unsuccessful Logon Attempts: lockout mechanisms protect cryptographic systems from brute-force authentication attacks.
• AC-17 — Remote Access: remote access channels depend on cryptographic protections to secure sessions and authenticate users.
• AC-18 — Wireless Access: wireless communications require cryptographic protocols to prevent interception and unauthorized access.
• AC-19 — Access Control for Mobile Devices: mobile device encryption and certificate management rely on properly implemented cryptographic controls.
• AU-09 — Protection of Audit Information: cryptographic hashing and signing protect audit logs from tampering and ensure non-repudiation.
• AU-10 — Non-repudiation: digital signatures and cryptographic mechanisms provide the evidence needed to establish non-repudiation.
• CM-11 — User-installed Software: code-signing validation prevents unauthorized or tampered software from executing on managed systems.
• CP-09 — System Backup: backup encryption ensures that copies of sensitive data remain protected even when stored offsite or in secondary environments.

Frequently asked questions

What is NIST SP 800-53 SC-13?

SC-13 is the NIST SP 800-53 control that requires organizations to identify all cryptographic uses across their systems and implement the appropriate type of cryptography for each one. It applies to all three baselines (LOW, MODERATE, HIGH), making it a foundational requirement for any federal or regulated system. The control covers all forms of cryptographic use, including encryption, digital signatures, hashing, and random number generation.

What happens if SC-13 is not implemented?

Without SC-13 controls in place, cryptographic module validation certificates may lapse or never exist, leaving systems reliant on non-FIPS-validated algorithms that don’t meet federal requirements. Sensitive data can be exposed in transit or at rest because no validated encryption mechanism protects it. Organizations also lose the ability to demonstrate compliance during audits, since auditors look for documented cryptographic use inventories and matching validation evidence.

How do you audit SC-13?

Auditors examine the cryptographic use inventory to confirm that every system-level cryptographic use has been identified and matched to a specific algorithm and module. They verify that each cryptographic module holds a current FIPS 140-2 or FIPS 140-3 validation certificate and is operating in an approved mode. The audit also includes reviewing system configuration settings for TLS versions, cipher suites, and encryption-at-rest implementations, along with interviewing personnel responsible for key management procedures.

What is FIPS-validated cryptography?

FIPS-validated cryptography refers to cryptographic modules that have been tested and certified through the Cryptographic Module Validation Program (CMVP) run by NIST and the Canadian Centre for Cyber Security. Each validated module receives a certificate number that organizations can reference to prove compliance with SC-13 requirements. The validation process tests the module against the FIPS 140-2 or FIPS 140-3 standard, confirming that it implements approved algorithms correctly and meets security requirements for key management, self-testing, and tamper evidence.