SC-23(5): Allowed Certificate Authorities

The sc-23(5): allowed certificate authorities requirement is a narrow control with outsized blast radius. If a system trusts too many CAs, a single mis-issued certificate, compromised CA, or unapproved private PKI can enable interception or impersonation of critical services. If it trusts too few, business breaks: outbound SaaS calls fail, inbound customer traffic gets blocked, and teams bypass controls with “temporary” exceptions that never expire.

SC-23(5) is also one of those requirements that auditors expect to be concrete. They will ask: “Which CAs are allowed?” and “Show me where that’s enforced.” A narrative policy without technical enforcement usually fails the smell test. You need a short list (or controlled process for maintaining one), plus configuration proof across the places trust is decided: endpoint trust stores, application runtimes, container images, outbound proxies, TLS inspection, and inbound termination.

This page gives requirement-level guidance you can implement quickly: what to allow, where to enforce it, how to handle exceptions, and what evidence to retain so you can pass an assessment without scrambling.

Regulatory text

Requirement (SC-23(5)): “Only allow the use of {{ insert: param, sc-23.05_odp }} for verification of the establishment of protected sessions.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning: you must constrain which certificate authorities can be used to validate certificates during protected session setup (typically TLS). In practice, that means an explicit allowlist of trusted CAs (public roots and/or your internal PKI) and technical controls that prevent the system from trusting any CA outside that list for session establishment. (NIST SP 800-53 Rev. 5)

Plain-English interpretation (what the control is really asking)

Protected sessions (TLS, and similar mechanisms) rely on certificate path validation back to a trusted CA. SC-23(5) expects you to:

1. Decide which CAs are acceptable for your environment and use cases.
2. Enforce that decision so endpoints and services cannot silently trust “whatever is in the default store.”
3. Prove the enforcement through configuration evidence and governance records.

This is not a “have a PKI” requirement. It is a trust restriction requirement: an allowlist (or tightly governed trust policy) for CA roots/intermediates used in session verification. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entities

• Federal information systems and contractor systems handling federal data implementing NIST SP 800-53 controls. (NIST SP 800-53 Rev. 5)

Operational context (where you must care)

• Inbound TLS termination: load balancers, API gateways, ingress controllers, WAFs.
• Outbound TLS: egress proxies, secure web gateways, service-to-service calls, SaaS integrations.
• Endpoints and user agents: managed devices, VDI, browsers, thick clients.
• Workloads: container base images, JVM/.NET/Node/Python trust bundles, service mesh sidecars.
• TLS inspection / decryption: any device that re-signs traffic with an enterprise CA.

If any of these validate a certificate during session setup, SC-23(5) is in scope. (NIST SP 800-53 Rev. 5)

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

Step 1: Name the control owner and decision forum

Assign a single accountable owner (often Security Engineering, PKI team, or Network Security) and define who approves changes to the allowed CA set (for example, CAB or security exception committee). Auditors look for accountability as much as they look for configuration. (NIST SP 800-53 Rev. 5)

Output: RACI entry + control statement in your control library mapped to SC-23(5). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 2: Define your “allowed CA” policy (the allowlist)

Create an “Allowed Certificate Authorities Standard” with:

• Allowed public roots (named CA programs or specific root fingerprints).
• Allowed private roots/intermediates (enterprise PKI hierarchy, including cross-signed intermediates if used).
• Disallowed categories (example: consumer device-manufacturer roots, adware roots, “trust all corporate roots” on servers).
• Scope notes: separate rules for endpoints vs servers vs controlled inspection points.

Keep it concrete. “We trust major public CAs” is not an allowlist.

Practical pattern: maintain a machine-readable list (fingerprints/SPKI pins or PEMs) plus a human-readable change log tied to approvals. (NIST SP 800-53 Rev. 5)

Step 3: Inventory where trust is enforced (your “trust decision points”)

Build an inventory of systems that:

• Terminate TLS,
• Initiate outbound TLS,
• Perform TLS inspection,
• Ship trust stores as part of images or runtimes.

Examples to include:

• Windows/macOS/Linux trust stores on managed fleets
• Java cacerts, Node/OpenSSL bundles, Python certifi
• NGINX/Envoy/HAProxy CA bundles
• Kubernetes admission policies for image scanning of CA bundles
• Egress proxy trust configuration

Output: a “Trust Enforcement Points” register that maps each platform to an enforcement method and evidence source. (NIST SP 800-53 Rev. 5)

Step 4: Implement technical enforcement (by platform)

Use the tightest control your architecture allows:

A. Managed endpoints

• Push an enterprise-approved trust store baseline via MDM/GPO.
• Remove or disable unapproved roots where feasible; where removal is not feasible, use browser/agent policies that restrict trust for enterprise apps.

B. Servers and workloads

• Bake approved CA bundles into golden images and base containers.
• For app runtimes, set explicit CA paths (do not inherit host defaults without review).
• For service-to-service, prefer mutual TLS with your internal CA and constrain intermediates.

C. Network controls

• Configure secure web gateways/egress proxies to validate upstream certificates against the allowed CA set.
• For TLS inspection, ensure the inspection CA is explicitly approved, its private keys are protected, and its distribution is controlled (this becomes part of your allowed CA set by design).

D. Inbound termination

• For client-certificate auth (mTLS), configure allowed client CA chains explicitly.
• For public-facing TLS where you present certificates, ensure your issuance CA is approved; while SC-23(5) targets verification, examiners often ask how you prevent drift into unapproved issuance relationships.

Enforcement test: attempt a connection to a site/service signed by a deliberately unapproved CA (in a test environment) and show it fails at handshake with a validation error. Capture logs/screenshots and config snippets. (NIST SP 800-53 Rev. 5)

Step 5: Exception handling that does not rot

You will need exceptions (legacy partner, niche SaaS, embedded device). Put guardrails in writing:

• Business justification
• Compensating controls (pinning, mTLS, egress allowlisting, additional monitoring)
• Expiration criteria and planned remediation
• Approver and date

Track exceptions in a register that security can report on. If you cannot expire exceptions reliably, auditors will treat the allowlist as aspirational. (NIST SP 800-53 Rev. 5)

Step 6: Monitoring and recurring review

Operationalize drift detection:

• Scheduled checks of trust stores against the approved list
• Alerts on new root additions in managed fleets
• CI/CD checks that container images do not add unauthorized roots
• Periodic review of the allowed CA list (including CA program changes and internal PKI changes)

If you use Daydream to manage control operations, the practical win is centralizing: control ownership, the approved CA list, the exception register, and recurring evidence collection reminders tied to SC-23(5) so you are not rebuilding the story each assessment cycle. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Keep evidence that shows definition, enforcement, and ongoing operation:

1. Allowed Certificate Authorities Standard
   • Approved allowlist (hashes/fingerprints or PEM bundle)
   • Approval record and change log
2. Trust Enforcement Points register
   • Systems in scope, enforcement location, owner, evidence pointer
3. Configuration evidence (representative samples)
   • GPO/MDM policy exports
   • Server config snippets (NGINX/Envoy/HAProxy), runtime CA settings
   • Proxy/SWG policy exports
   • Kubernetes/IaC policy-as-code outputs
4. Test evidence
   • Handshake failure proof for unapproved CA (logs, packet capture summary, screenshots)
5. Exception register
   • Approved exceptions with compensating controls and review/expiry
6. Review and monitoring records
   • Drift scan results, alerts, remediation tickets, review meeting notes

Map each artifact to SC-23(5) in your control matrix so assessors can follow the thread quickly. (NIST SP 800-53 Rev. 5)

Common exam/audit questions and hangups

Assessors tend to get stuck on a few specifics:

• “Show me the list.” They want the allowed CA set in an auditable form, not “default OS trust store.”
• “Where is it enforced?” Expect to demonstrate enforcement at multiple layers, especially outbound egress and server workloads.
• “How do you prevent drift?” Default trust stores change with patches; container images get rebuilt; developers add custom CA bundles.
• “What about TLS inspection?” If you intercept TLS, your inspection CA becomes a high-value trust anchor. They will ask how it’s controlled and where it is installed.
• “Do third parties introduce new trust?” Partners sometimes require installing their private root. That is a governance and exception-management test.

Frequent implementation mistakes (and how to avoid them)

1. Calling the OS default store an allowlist. Avoidance: extract and approve a specific list, then lock it down with management controls and monitoring. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. Forgetting runtime trust stores. Java, Node, and containers can bypass host policies. Avoidance: require explicit CA configuration in build standards and CI checks.
3. No exception expirations. “Temporary” partner roots stay forever. Avoidance: require expirations and block renewal without remediation progress.
4. Enforcing only inbound, ignoring outbound. Most sensitive data flows occur outbound to SaaS and APIs. Avoidance: enforce at egress proxies and in application configs.
5. TLS inspection without tight key management. If the inspection CA key is poorly controlled, the allowlist becomes meaningless. Avoidance: treat inspection CA like a critical secret with strict access control and rotation procedures.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SC-23(5) as an assessment-driven control rather than citing specific penalties. The practical risk is straightforward: overly broad CA trust increases the chance of successful impersonation or interception of protected sessions, and weak evidence increases the chance of audit findings for control design/operation gaps. (NIST SP 800-53 Rev. 5)

Practical execution plan (30/60/90-day)

Use this as an operator’s rollout path. Adjust sequencing to match where you have the most TLS exposure.

First 30 days (Immediate)

• Assign control owner and approvers; publish a one-page control narrative mapped to SC-23(5). (NIST SP 800-53 Rev. 5)
• Draft the allowed CA standard with an initial list (public + internal) and an exception workflow.
• Build the trust decision point inventory for high-risk paths (egress proxy, ingress gateway, fleet endpoints, core workloads).
• Capture baseline evidence (current trust stores/configs) so you can prove improvement later.

Days 31–60 (Near-term)

• Enforce allowed CA sets on managed endpoints and at outbound egress where possible.
• Update golden images/base containers to contain only approved roots for server/workload tiers.
• Implement CI/CD checks for unauthorized CA additions (container layer scanning, repo policy checks).
• Stand up the exception register and migrate any “known special roots” into governed exceptions.

Days 61–90 (Operationalize)

• Expand enforcement coverage to remaining platforms (service mesh, legacy apps, specialty appliances).
• Run a controlled negative test and document handshake failures against unapproved CAs; store evidence centrally.
• Add drift monitoring and a recurring review cadence for the allowlist, exceptions, and enforcement coverage.
• Package the evidence set for assessment: policy, configs, tests, exception records, and review logs mapped to SC-23(5). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

Does SC-23(5) mean we must run our own private CA?

No. It requires you to restrict which CAs are allowed for verifying protected sessions. Your allowed set can include public roots, your private PKI, or both, as long as you can show explicit approval and enforcement. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Is using the default OS/browser trust store compliant?

It can be, but only if you treat it as a controlled allowlist: you define what “allowed” means, demonstrate configuration control, and monitor for drift. Many teams fail audits because they cannot show explicit approval and enforcement of the CA set. (NIST SP 800-53 Rev. 5)

How do we handle SaaS providers that change issuing intermediates?

Decide whether your allowlist is root-based or intermediate-based and document the rule. Use an exception process for urgent changes, then fold stable changes into the approved list with an approval record and updated evidence. (NIST SP 800-53 Rev. 5)

What systems are usually missed in CA allowlisting efforts?

Application runtimes and containers are the common misses because they ship their own CA bundles. Add build standards and CI checks so developers cannot quietly add new roots. (NIST SP 800-53 Rev. 5)

We do TLS inspection. Does that violate SC-23(5)?

Not inherently, but your inspection CA becomes part of what systems trust for protected sessions. You need strict governance over where that CA is installed, who can issue with it, and how its keys are protected, plus evidence that only approved inspection trust anchors exist. (NIST SP 800-53 Rev. 5)

What evidence is most persuasive to auditors?

A clear allowed CA list with approvals, plus technical exports showing enforcement at key trust points (endpoint policy, proxy config, workload/runtime CA configuration), and a negative test that fails handshake validation for an unapproved CA. (NIST SP 800-53 Rev. 5 OSCAL JSON)