NIST SP 800-52 Revision 2 is the authoritative guide for configuring TLS in federal information systems — and increasingly, the baseline that enterprise security teams reference for their own TLS policies. Published in August 2019, it defines which TLS versions, cipher suites, extensions, and certificate configurations are acceptable for systems processing government data.
If you’re pursuing FedRAMP authorization, handling CUI (Controlled Unclassified Information), or simply want a defensible TLS configuration standard, this is the document your auditors will reference. Here’s what it requires and how to implement it.
Scope and Applicability
SP 800-52 Rev 2 applies to:
- Federal agencies and their information systems
- Contractors processing federal data (CUI, FISMA systems)
- FedRAMP cloud service providers
- Any organization adopting NIST guidelines as their TLS baseline
It covers both TLS servers (web servers, API endpoints, mail servers) and TLS clients (browsers, API consumers, mail clients) — with different requirements for each.

Protocol Version Requirements
What’s Allowed
| Protocol | Server | Client | Notes |
|---|---|---|---|
| TLS 1.3 | SHALL support | SHALL support | Preferred for all new deployments |
| TLS 1.2 | SHALL support | SHALL support | Required for backward compatibility |
| TLS 1.1 | SHALL NOT support | SHALL NOT support | Deprecated — disable immediately |
| TLS 1.0 | SHALL NOT support | SHALL NOT support | Deprecated — disable immediately |
| SSL 3.0 | SHALL NOT support | SHALL NOT support | Broken (POODLE) — must be disabled |
| SSL 2.0 | SHALL NOT support | SHALL NOT support | Catastrophically broken |
Key distinction: “SHALL” in NIST language means mandatory. There’s no wiggle room — if your server still accepts TLS 1.0 connections, you’re non-compliant.
Implementation
# Verify which protocols a server supports
openssl s_client -connect server.example.com:443 -tls1_3
openssl s_client -connect server.example.com:443 -tls1_2
openssl s_client -connect server.example.com:443 -tls1_1 # Should FAIL
openssl s_client -connect server.example.com:443 -tls1 # Should FAIL
Cipher Suite Requirements
SP 800-52 Rev 2 specifies approved cipher suites by referencing NIST SP 800-56A (key establishment) and SP 800-56C (key derivation). In practice, this means:
TLS 1.3 Cipher Suites (All Approved)
TLS 1.3 simplified the cipher suite landscape. All three standard suites are NIST-approved:
| Cipher Suite | Status | Notes |
|---|---|---|
TLS_AES_256_GCM_SHA384 | Approved | Strongest option |
TLS_AES_128_GCM_SHA256 | Approved | Good performance/security balance |
TLS_CHACHA20_POLY1305_SHA256 | Approved | Preferred for mobile/ARM |
TLS 1.2 Approved Cipher Suites
For TLS 1.2, only specific combinations are approved:
| Cipher Suite | Key Exchange | Encryption | Status |
|---|---|---|---|
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ECDHE + ECDSA | AES-256-GCM | Preferred |
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ECDHE + ECDSA | AES-128-GCM | Preferred |
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ECDHE + RSA | AES-256-GCM | Approved |
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ECDHE + RSA | AES-128-GCM | Approved |
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | DHE + RSA | AES-256-GCM | Approved (2048+ DH) |
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | DHE + RSA | AES-128-GCM | Approved (2048+ DH) |
Explicitly Prohibited
| Pattern | Reason |
|---|---|
Any cipher with RC4 | Broken — biases in keystream |
Any cipher with 3DES / DES | Insufficient block size (Sweet32 attack) |
Any cipher with NULL encryption | No confidentiality |
Any cipher with EXPORT | Intentionally weakened (FREAK/Logjam) |
Any cipher with MD5 MAC | Collision attacks |
Static RSA key exchange (no DHE/ECDHE) | No forward secrecy |
CBC-mode ciphers without Encrypt-then-MAC | Padding oracle attacks (BEAST, Lucky13) |
Practical Configuration
Nginx (NIST SP 800-52 compliant):
server {
listen 443 ssl;
server_name api.example.gov;
# Protocol versions — TLS 1.2 and 1.3 only
ssl_protocols TLSv1.2 TLSv1.3;
# Cipher suites — NIST-approved only, prefer ECDHE + AESGCM
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
# ECDHE curve — NIST P-256 or P-384
ssl_ecdh_curve secp384r1:secp256r1;
# DHE parameters — minimum 2048-bit
ssl_dhparam /etc/nginx/dhparam-4096.pem;
# Session configuration
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Disable for forward secrecy
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
# Certificate
ssl_certificate /etc/nginx/certs/server-chain.pem;
ssl_certificate_key /etc/nginx/certs/server.key;
ssl_trusted_certificate /etc/nginx/certs/ca-chain.pem;
}
Apache (NIST SP 800-52 compliant):
<VirtualHost *:443>
ServerName api.example.gov
SSLEngine on
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder on
# Disable compression (CRIME attack)
SSLCompression off
# OCSP stapling
SSLUseStapling on
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
# Certificate files
SSLCertificateFile /etc/httpd/certs/server.crt
SSLCertificateKeyFile /etc/httpd/certs/server.key
SSLCertificateChainFile /etc/httpd/certs/ca-chain.crt
</VirtualHost>
Generate 4096-bit DH parameters:
openssl dhparam -out /etc/nginx/dhparam-4096.pem 4096
# This takes several minutes — generate once, deploy everywhere
Certificate Requirements
SP 800-52 Rev 2 specifies requirements for server certificates used in TLS:
Key Size Requirements
| Algorithm | Minimum Key Size | Recommended | Notes |
|---|---|---|---|
| RSA | 2048 bits | 3072+ bits | 2048 acceptable through 2030 per SP 800-57 |
| ECDSA | P-256 (256 bits) | P-384 | Equivalent to RSA 3072 / RSA 7680 |
| EdDSA | Ed25519 | Ed448 | Not yet widely supported in TLS |
Signature Algorithm Requirements
| Algorithm | Status |
|---|---|
| SHA-256 with RSA/ECDSA | Approved |
| SHA-384 with RSA/ECDSA | Approved |
| SHA-512 with RSA/ECDSA | Approved |
| SHA-1 with RSA/ECDSA | NOT approved (prohibited for new certs) |
| MD5 with RSA | NOT approved |
Certificate Validation Requirements
Servers SHALL:
- Present a complete certificate chain (leaf + intermediates)
- Include the server’s FQDN in the Subject Alternative Name (SAN) extension
- Use certificates signed with approved algorithms (SHA-256+)
- Support OCSP stapling (SHOULD)
Clients SHALL:
- Validate the full certificate chain to a trusted root
- Check certificate revocation status (CRL or OCSP)
- Verify the server’s hostname matches the certificate SAN
- Reject expired certificates
- Reject certificates with key sizes below minimum

TLS Extension Requirements
Required Extensions
| Extension | Requirement | Purpose |
|---|---|---|
| Server Name Indication (SNI) | SHALL support (server + client) | Virtual hosting, correct cert selection |
| Supported Versions | SHALL (TLS 1.3) | Protocol version negotiation |
| Signature Algorithms | SHALL support | Advertise acceptable signature methods |
| Key Share | SHALL (TLS 1.3) | ECDHE key exchange in first flight |
| Extended Master Secret | SHALL support (TLS 1.2) | Prevents triple handshake attack |
Recommended Extensions
| Extension | Requirement | Purpose |
|---|---|---|
| OCSP Stapling (status_request) | SHOULD support | Efficient revocation checking |
| Certificate Transparency (SCT) | SHOULD support | Detect misissued certificates |
| ALPN | SHOULD support | Protocol negotiation (HTTP/2, HTTP/3) |
Prohibited Behaviors
| Behavior | Reason |
|---|---|
| TLS compression | CRIME attack — leaks plaintext through compression ratios |
Renegotiation without renegotiation_info | Renegotiation attack (CVE-2009-3555) |
| Session tickets without rotation | Compromised ticket key breaks forward secrecy |
| Truncated HMAC | Weakens integrity protection |
Compliance Mapping
SP 800-52 vs Other Standards
| Requirement | SP 800-52 Rev 2 | PCI DSS 4.0 | HIPAA | FedRAMP |
|---|---|---|---|---|
| Minimum TLS version | TLS 1.2 | TLS 1.2 | TLS 1.2 | TLS 1.2 (references 800-52) |
| Forward secrecy | Required (ECDHE/DHE) | Recommended | Not specified | Required (references 800-52) |
| Certificate key size | RSA 2048+ / ECDSA P-256+ | RSA 2048+ | Not specified | RSA 2048+ (references 800-52) |
| Revocation checking | Required (CRL/OCSP) | Required | Not specified | Required |
| Session ticket rotation | Required | Not specified | Not specified | Required |
| OCSP stapling | Recommended | Not specified | Not specified | Recommended |
FIPS 140 Relationship
SP 800-52 requires that cryptographic modules used for TLS be FIPS 140-2 (or 140-3) validated when processing federal data. This means:
- The TLS library (OpenSSL, NSS, SChannel, BoringSSL) must operate in FIPS mode
- Random number generation must use a DRBG from SP 800-90A
- Key generation must follow SP 800-133
# Check if OpenSSL is running in FIPS mode
openssl version -a | grep FIPS
# Enable FIPS mode in OpenSSL 3.x
# Edit /etc/ssl/openssl.cnf:
# [openssl_init]
# providers = provider_sect
# [provider_sect]
# fips = fips_sect
# [fips_sect]
# activate = 1
Auditing Your TLS Configuration
Using testssl.sh
# Comprehensive TLS audit against NIST requirements
testssl.sh --protocols --ciphers --server-defaults --vulnerabilities https://api.example.gov
# Key checks:
# - No TLS 1.0/1.1 support
# - No RC4, 3DES, NULL, EXPORT ciphers
# - Forward secrecy on all cipher suites
# - Certificate key size ≥ 2048 RSA / P-256 ECDSA
# - SHA-256+ signature algorithm
# - OCSP stapling enabled
# - No known vulnerabilities (BEAST, POODLE, Heartbleed, etc.)
Using OpenSSL
# Check protocol support
for proto in tls1 tls1_1 tls1_2 tls1_3; do
echo -n "$proto: "
openssl s_client -connect api.example.gov:443 -$proto 2>/dev/null | grep "Protocol" || echo "NOT SUPPORTED"
done
# List accepted cipher suites
openssl s_client -connect api.example.gov:443 -tls1_2 2>/dev/null | grep "Cipher is"
openssl s_client -connect api.example.gov:443 -tls1_3 2>/dev/null | grep "Cipher is"
# Check certificate details
openssl s_client -connect api.example.gov:443 -servername api.example.gov 2>/dev/null | \
openssl x509 -noout -text | grep -E "Public-Key|Signature Algorithm|Subject Alternative"
Compliance Checklist
| # | Check | Pass Criteria | Command |
|---|---|---|---|
| 1 | TLS 1.0 disabled | Connection refused | openssl s_client -tls1 |
| 2 | TLS 1.1 disabled | Connection refused | openssl s_client -tls1_1 |
| 3 | TLS 1.2 enabled | Connection succeeds | openssl s_client -tls1_2 |
| 4 | TLS 1.3 enabled | Connection succeeds | openssl s_client -tls1_3 |
| 5 | No RC4 ciphers | Handshake failure | openssl s_client -cipher RC4 |
| 6 | No 3DES ciphers | Handshake failure | openssl s_client -cipher 3DES |
| 7 | Forward secrecy | All ciphers use ECDHE/DHE | Check cipher list |
| 8 | RSA key ≥ 2048 | Key size in cert | openssl x509 -noout -text |
| 9 | SHA-256+ signature | No SHA-1 in chain | Check signature algorithm |
| 10 | OCSP stapling | Stapled response present | openssl s_client -status |
| 11 | Complete chain | No missing intermediates | openssl s_client -showcerts |
| 12 | SAN present | DNS names in SAN | openssl x509 -noout -ext subjectAltName |
What Changed from Rev 1 to Rev 2
| Area | Rev 1 (2014) | Rev 2 (2019) |
|---|---|---|
| TLS 1.3 | Not covered (didn’t exist) | Full support and guidance |
| TLS 1.0 | Allowed with restrictions | Prohibited |
| TLS 1.1 | Allowed | Prohibited |
| RSA key exchange | Allowed (no PFS) | Prohibited (must use ECDHE/DHE) |
| CBC ciphers | Allowed | Discouraged (GCM preferred) |
| 3DES | Allowed with restrictions | Prohibited |
| ECDHE curves | P-256, P-384, P-521 | P-256, P-384 (P-521 removed) |
| Session tickets | Allowed | Allowed with key rotation requirements |
| Extended Master Secret | Not covered | Required for TLS 1.2 |
| Certificate Transparency | Not covered | Recommended |
Looking Ahead: Post-Quantum Considerations
SP 800-52 Rev 2 was published before NIST finalized post-quantum standards. A future revision will likely address:
- Hybrid key exchange (ML-KEM + ECDHE) for TLS 1.3
- Larger certificate sizes from post-quantum signature algorithms (ML-DSA certificates are ~2.5KB vs ~1KB for RSA)
- Performance impact of PQC on TLS handshakes
- Migration timeline aligned with CNSA 2.0 deadlines
For now, organizations should:
- Ensure TLS 1.3 is deployed everywhere (it’s the foundation for PQC hybrid modes)
- Monitor NIST’s PQC migration guidance (SP 800-227, expected 2026)
- Test hybrid key exchange in non-production environments
- Maintain crypto-agility to swap algorithms without infrastructure changes
FAQ
Q: Is SP 800-52 Rev 2 mandatory for private companies?
Not directly. It’s mandatory for federal agencies and their contractors. However, many private organizations adopt it as their TLS baseline because it’s well-researched, regularly updated, and provides a defensible standard for auditors. If you’re pursuing SOC 2 or ISO 27001, referencing SP 800-52 demonstrates due diligence.
Q: Can I still use TLS 1.2 CBC cipher suites?
SP 800-52 Rev 2 doesn’t explicitly prohibit CBC ciphers in TLS 1.2, but strongly recommends GCM (AEAD) ciphers instead. CBC ciphers have a history of padding oracle vulnerabilities (BEAST, Lucky13). For new deployments, use GCM exclusively. For legacy systems that require CBC, ensure the Encrypt-then-MAC extension is negotiated.
Q: Does SP 800-52 require FIPS-validated TLS libraries?
For federal systems — yes. The cryptographic module performing TLS operations must be FIPS 140-2 or 140-3 validated. For private organizations, this depends on your compliance requirements (FedRAMP requires it, PCI DSS does not).
Q: How does SP 800-52 relate to CNSA 2.0?
CNSA 2.0 (NSA’s Commercial National Security Algorithm Suite) is more restrictive — it targets national security systems and mandates specific algorithms for classified data. SP 800-52 covers general federal systems. CNSA 2.0 requires AES-256 (not 128), SHA-384 (not 256), and P-384 curves (not P-256). If you need CNSA 2.0 compliance, SP 800-52 is necessary but not sufficient.
Q: What about mutual TLS (mTLS) — does SP 800-52 cover client certificates?
Yes. Section 4 covers TLS client requirements, including client certificate authentication. Client certificates must meet the same key size and signature algorithm requirements as server certificates. The server must validate the client certificate chain and check revocation status.
Q: How often should I re-audit TLS configuration?
At minimum, after any infrastructure change (server rebuild, load balancer update, certificate renewal). Ideally, continuously — configuration drift happens when someone troubleshoots a connectivity issue and enables TLS 1.0 “temporarily.” Automated scanning catches these regressions before auditors do.
Related Reading: