SC-13(2): NSA-approved Cryptography

SC-13(2) requires you to use NSA-approved cryptography for the systems and data flows in scope, and to be able to prove it with implementation evidence. Operationalize it by defining where NSA-approved cryptography is mandatory, standardizing approved modules/profiles, validating configurations in production, and retaining artifacts that show crypto selection, deployment, and ongoing monitoring. ¹

Key takeaways:

• Scope first: identify which environments and communications require NSA-approved cryptography before selecting products.
• Standardize “approved” into build templates, not exceptions, and block non-approved crypto through configuration and change control.
• Audits fail on evidence gaps, not intent; retain configuration outputs, architecture diagrams, and system inventory mappings. ²

The sc-13(2): nsa-approved cryptography requirement is a specificity control: it narrows acceptable cryptographic approaches to those approved by the National Security Agency (NSA) for applicable systems. For a CCO, GRC lead, or Compliance Officer, the work is less about choosing an algorithm in a policy document and more about translating “NSA-approved” into enforceable engineering standards, procurement constraints, and repeatable evidence.

Treat SC-13(2) as a control that must be testable on real assets. That means you should be able to point an assessor to (1) a scoped list of systems and data flows that require NSA-approved cryptography, (2) the technical standard that defines what “approved” means in your environment, (3) production configurations proving those standards are implemented, and (4) monitoring and change control that keep crypto from drifting over time.

NIST SP 800-53 is a control framework, not a product checklist. Your goal is to set a defensible, auditable implementation approach that security engineering can execute and procurement can enforce across first-party systems and relevant third parties. ²

What SC-13(2) means in plain English

SC-13(2) is asking for one thing: when cryptography is required, you must use cryptography that is approved by NSA, and you must be able to demonstrate that decision and implementation in practice. ¹

In operational terms, “NSA-approved” typically shows up in federal contexts where organizations are expected to follow NSA-approved approaches for protecting national security systems or for specific high-assurance use cases. As a compliance operator, do not leave this as a vague policy statement. Define:

• Which systems and environments are in scope
• Which cryptographic modules, protocols, and configurations are acceptable
• How you prevent non-approved crypto from being introduced
• What evidence you retain to prove continuous compliance

Regulatory text

NIST provides the control enhancement reference for this requirement as: “NIST SP 800-53 control SC-13.2.” with the summary “SC-13(2): NSA-approved Cryptography.” ¹

What the operator must do: implement cryptography that meets the “NSA-approved” bar for in-scope systems and communications, and maintain documentation and technical evidence that ties those cryptographic choices to the system boundary and the real configurations running in production. ²

Who it applies to (entity and operational context)

This requirement is most relevant for:

• Federal information systems implementing NIST SP 800-53 controls as part of their authorization and ongoing assessment program. ²
• Contractor systems handling federal data where NIST SP 800-53 controls (or an overlay derived from them) are incorporated into contract requirements, security plans, or assessment criteria. ¹

Operational contexts where SC-13(2) commonly becomes “real”:

• High-assurance enclaves, restricted networks, or specialized programs with explicit NSA crypto expectations
• Systems supporting sensitive federal missions where cryptographic approvals are scrutinized in design reviews
• Third-party hosted environments where you must prove the crypto posture of managed services and endpoints

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

Use this sequence to make SC-13(2) executable.

1) Establish scope and decision authority

1. Define the in-scope boundary (systems, environments, and data flows) where “NSA-approved cryptography” is mandatory. Tie this to your system boundary documentation and data flow diagrams.
2. Assign a control owner (security architecture or crypto engineering) and a compliance owner (GRC) who is accountable for evidence readiness.
3. Define exceptions governance: who can approve deviations, what compensating controls are required, and how expiration/renewal works.

Deliverable: a short SC-13(2) implementation standard that states “where required” and “who decides.” ²

2) Translate “NSA-approved” into enforceable technical standards

1. Create an “Approved Cryptography Standard” for your environment. Do not stop at “use strong encryption.” Specify what engineers must configure (protocol versions, cipher suites, key handling expectations, and approved libraries/modules) in your build standards.
2. Map the standard to platforms you run (endpoints, servers, containers, network appliances, mobile, SaaS integrations). Your standard should be implementable in configuration code or baseline templates.

Deliverable: a technical standard with platform-specific implementation notes that engineering can follow and auditors can test. ¹

3) Inventory where cryptography is used (and where it must be)

1. System inventory mapping: for each in-scope system, record where cryptography is used for data in transit and data at rest.
2. Data flow mapping: identify ingress/egress points, service-to-service flows, and external integrations (including third parties).
3. Dependency mapping: enumerate crypto-relevant components such as TLS termination points, HSM/KMS services, certificate authorities, VPN gateways, and database encryption features.

Deliverable: a “crypto usage register” tied to your asset inventory and architecture diagrams.

4) Implement and lock configurations in production

1. Harden crypto configurations using baseline templates (gold images, IaC modules, MDM profiles, load balancer policies).
2. Centralize certificate and key management through approved services and documented processes.
3. Prevent drift through CI/CD checks, configuration management rules, and change control gates for any crypto-impacting changes (TLS policies, library upgrades, certificate rotations).

Deliverable: versioned baseline configurations and production configuration evidence (outputs, screenshots, or configuration exports) that show the enforced crypto posture.

5) Validate continuously (not just at go-live)

1. Add validation checks: scanning for protocol versions/cipher suites, checking certificate properties, and confirming encryption settings on storage services.
2. Create an evidence cadence aligned to your assessment cycle: recurring exports/reports that prove the crypto standard remains enforced.
3. Track remediation: issues become tickets with owner, due date, and closure evidence.

Deliverable: repeatable test results plus a remediation log that shows control operation over time. ²

6) Extend to third parties where they touch your boundary

1. Contractual requirements: require third parties to meet your crypto standard where they process or transmit in-scope federal data.
2. Due diligence: collect architecture and configuration attestations, and require evidence for managed termination points (CDNs, API gateways, hosted load balancers).
3. Ongoing monitoring: require notice of crypto changes that impact your environment (e.g., TLS policy changes).

Deliverable: third-party due diligence artifacts and contract language excerpts tied to the same “approved cryptography” standard.

Required evidence and artifacts to retain

Assessments commonly fail because teams cannot show how the standard is implemented on real assets. Keep evidence that is traceable from requirement → system → configuration.

Minimum evidence set (practical):

• SC-13(2) control narrative: scope, owner, how NSA-approved cryptography is defined internally, and how compliance is verified. ²
• Cryptography standard / configuration baseline: approved protocols and configurations; platform mappings.
• System inventory mapping showing in-scope systems and crypto touchpoints.
• Architecture diagrams + data flow diagrams marking encryption points and termination locations.
• Production configuration evidence: exports or settings snapshots for TLS policies, database encryption, storage encryption, and key management.
• Change control records for crypto-impacting changes (approvals, testing, rollback plans).
• Monitoring/validation outputs: periodic scan results and remediation tickets.

If you use Daydream to manage control operations, set SC-13(2) to a named owner, attach the standard and baseline templates, and schedule recurring evidence collection so you do not rebuild the evidence trail during assessment.

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “Show me which systems are in scope for NSA-approved cryptography and why.”
• “What does ‘NSA-approved’ mean in your environment? Where is it defined?”
• “Prove the TLS configuration on your external endpoints and internal service mesh.”
• “Where are keys generated, stored, rotated, and revoked?”
• “How do you prevent engineers from deploying non-compliant cipher suites?”
• “How do you validate third-party managed components that terminate TLS?”

Hangup patterns:

• Policy says “approved crypto,” but production configs are inconsistent.
• Scope is undocumented, so everything becomes an argument.
• Evidence is ad hoc screenshots without traceability to inventory items.

Frequent implementation mistakes and how to avoid them

Mistake: Treating SC-13(2) as a one-time design decision.
Fix: Create a recurring validation routine and tie it to change control for crypto-impacting changes. ²

Mistake: Assuming a cloud provider’s default settings satisfy the requirement.
Fix: Document your crypto responsibilities under the shared responsibility model and retain configuration exports that show your actual settings.

Mistake: No formal definition of “NSA-approved” for engineering.
Fix: Publish an internal cryptography standard with enforceable configuration requirements, then link it in your control narrative. ¹

Mistake: Ignoring TLS termination points owned by third parties.
Fix: Treat CDNs, WAFs, API gateways, and managed load balancers as crypto control points; collect their configurations and change notifications.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific control enhancement, so you should not plan around “case law” narratives here. ¹

Practical risk still matters:

• Authorization risk: inability to prove NSA-approved cryptography can lead to assessment findings and delays in ATO decisions for federal systems.
• Mission and confidentiality risk: weak or non-approved cryptography increases exposure if interception, downgrade attacks, or key compromise occurs.
• Supply chain risk: third parties can silently change crypto defaults; without contractual notice and monitoring, you may drift out of compliance.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and standards)

• Name the SC-13(2) control owner and evidence owner.
• Define in-scope systems and data flows; publish a one-page scope statement.
• Draft and approve the “NSA-approved cryptography” technical standard and exceptions process.
• Build the initial crypto usage register (high-value systems first). ²

Days 31–60 (implement baselines and start validation)

• Convert the standard into baseline configurations (IaC modules, TLS policies, MDM profiles).
• Implement change control triggers for crypto-impacting changes.
• Start periodic validation checks and capture repeatable evidence outputs.
• Update third-party templates (security addendum, due diligence request list) to reflect the crypto standard. ¹

Days 61–90 (prove operating effectiveness)

• Expand validation coverage across all in-scope systems and external endpoints.
• Run a mock assessment: sample systems, trace inventory → diagram → config evidence → monitoring results.
• Close gaps with tracked remediation and documented exceptions where needed.
• Operationalize recurring evidence collection in Daydream so the audit package is continuously current.

Frequently Asked Questions

Does SC-13(2) mean I must replace all cryptography everywhere?

No. It applies where your scope requires NSA-approved cryptography. Your first job is to define and document which systems and data flows are in scope, then standardize and prove the approved configurations. ²

What evidence is most convincing to auditors for SC-13(2)?

Configurations pulled from production systems (or authoritative management planes) mapped to a named system inventory item, plus a written crypto standard that defines “NSA-approved” for your environment. ²

How do I handle third parties that terminate TLS on my behalf (CDN/WAF/API gateway)?

Treat them as in-scope crypto control points. Require configuration evidence and change notification terms in contracts, and retain the artifacts alongside your own endpoint configuration evidence.

Can a policy statement alone satisfy SC-13(2)?

No. You need implementation evidence that the approved cryptography is deployed and remains enforced. A policy without production proof usually becomes an assessment finding. ¹

How should I manage exceptions to NSA-approved cryptography?

Use time-bounded exceptions with a documented risk rationale, compensating controls, and explicit approval. Keep exception records tied to specific assets and review them on a defined cadence.

Where does Daydream fit in operationalizing SC-13(2)?

Daydream is useful once you have the scope and standard. It helps assign ownership, map the requirement to procedures, and collect recurring evidence artifacts so you can demonstrate ongoing operation without scrambling before assessments. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5