SC-17: Public Key Infrastructure Certificates

Quick-reference card

What this control requires

SC-17 requires organizations to issue public key certificates under a formal certificate policy and restrict trust stores to approved certificate authorities only. Most teams treat certificate management as a routine infrastructure task, but SC-17 treats it as a trust decision. Every certificate authority (CA) in your trust store is an entity you’re authorizing to vouch for the identity of systems, services, and users across your environment.

In practice, this control has two distinct obligations. First, your organization must either operate its own public key infrastructure (PKI) under a documented certificate policy or obtain certificates from an approved, externally managed service provider. Second, you must actively manage the trust anchors in every certificate store your organization controls, ensuring only authorized root certificates are present. A trust anchor is the root of a certificate hierarchy, the CA whose trustworthiness is assumed rather than derived from another authority.

The stakes here are not abstract. If an unauthorized CA exists in your trust store, any certificate it issues will be accepted as valid by your systems. That means encrypted connections, authenticated sessions, and signed tokens can all be forged without triggering a single alert. SC-17 exists to close this gap by requiring organizations to formalize which CAs they trust and to actively govern certificate issuance rather than accepting defaults.

Why it matters

Organizations that rely on default trust stores without reviewing or restricting their contents inherit trust decisions made by browser vendors and operating system distributors. Those defaults include dozens of CAs, some of which your organization may have no relationship with and no reason to trust. Every additional CA in a trust store is an additional point of failure.

The consequences extend well beyond certificate validation. PKI underpins authentication mechanisms including single sign-on (SSO), mutual TLS (mTLS), code signing, and email encryption. A compromised or unauthorized CA doesn’t just enable traffic interception. It undermines every system that depends on certificate-based identity, from cloud provider endpoints to internal microservice communication.

Where this risk becomes concrete is in supply chain and endpoint deployment scenarios. An attacker who compromises an enterprise software deployment system (MITRE ATT&CK T1072) can modify the deployment package to install a rogue root certificate into the trust store of every managed endpoint. Once that rogue CA is trusted, the attacker can issue certificates for any domain, including internal services, cloud platforms, and external SaaS applications, and perform TLS interception against all encrypted traffic from affected machines. The interception is invisible to end users and applications because the TLS client reports a valid, trusted certificate chain.

T1606 (Forge Web Credentials) represents the downstream consequence. With a trusted CA under attacker control, forged SAML assertions, signed JSON Web Tokens (JWTs), and client certificates become feasible at scale. PKI-dependent authentication mechanisms, including many enterprise SSO deployments, rely on the integrity of the certificate hierarchy. An organization that hasn’t formally controlled which CAs it trusts, and that doesn’t audit its certificate stores for unauthorized entries, has no reliable mechanism to detect a compromised CA operating within its trust boundary.

What attackers exploit

• Rogue root CA installation (T1072): Attackers compromise software distribution or endpoint management systems to push unauthorized root certificates into trust stores across the fleet, enabling man-in-the-middle interception of all TLS-protected traffic.
• Forged web credentials (T1606): With a rogue CA trusted by endpoints, attackers issue valid-looking certificates for SAML assertions, JWTs, and client certificates, bypassing PKI-dependent authentication.
• Unaudited trust stores: Default operating system and browser trust stores contain dozens of pre-installed CAs. Without periodic review, organizations unknowingly trust CAs they have no relationship with, expanding the attack surface.
• Expired or misconfigured certificates: Organizations that lack a formal certificate lifecycle process allow certificates to expire or deploy with weak configurations, creating service outages and downgraded encryption.

How to implement

The most common failure mode for SC-17 is not that organizations lack certificates, it’s that they’ve never formalized which certificate authorities they trust and have no process for auditing trust stores across their endpoints.

For your organization

Start by documenting a formal certificate policy that defines which CAs your organization trusts, the process for requesting and issuing certificates, and the criteria for adding or removing trust anchors. This policy should specify whether you operate an internal CA, use an external managed PKI service, or both, along with the approval process for each path.

Next, inventory every trust store under your organization’s control. This inventory includes operating system trust stores on servers and endpoints, browser-specific trust stores, application-specific certificate stores (for example, Java keystores or custom service configurations), and container images that ship with their own root bundles. Each trust store should be compared against your approved CA list, and any unauthorized trust anchors should be flagged and removed.

Implement technical controls to prevent unauthorized modifications to trust stores. Group policy objects (GPOs) on Windows, configuration management tools like Ansible or Puppet, and mobile device management (MDM) for mobile endpoints can enforce a baseline set of approved root certificates and block unapproved additions. Monitor for changes to certificate stores using endpoint detection and response (EDR) tools or file integrity monitoring.

Establish a certificate lifecycle management process covering issuance, renewal, revocation, and expiration. Automated certificate management tools, such as those implementing the Automated Certificate Management Environment (ACME) protocol, reduce the risk of expired certificates causing outages or security gaps. Maintain a certificate inventory that tracks every certificate in use, its issuing CA, expiration date, and associated service.

Common mistakes include treating the operating system’s default trust store as inherently safe, failing to inventory application-level trust stores (which often diverge from the OS store), and neglecting certificate transparency log monitoring that could reveal unauthorized certificates issued for your domains. Review weak SSL configurations as part of your ongoing certificate hygiene.

For your vendors

When assessing vendor compliance with SC-17, focus on whether the vendor has formalized its PKI trust decisions or is operating on defaults.

Request the vendor’s certificate policy or PKI policy document. This document should define which CAs the vendor trusts, how certificates are issued and managed, and the process for approving new trust anchors. If the vendor cannot produce a written certificate policy, that gap itself is a finding.

Ask these specific questions during your assessment:

• Do you maintain a documented certificate policy governing certificate issuance and trust anchor management?
• How do you restrict which certificate authorities are trusted in your environment?
• What is your process for adding or removing root certificates from trust stores?
• Do you monitor certificate stores for unauthorized modifications?
• Do you use certificate transparency logs to detect unauthorized certificate issuance for your domains?
• What is your certificate lifecycle management process, including renewal and revocation?

Request evidence that the vendor regularly audits trust stores across its infrastructure. Look for automated reports showing approved versus actual trust anchors, change logs for trust store modifications, and incident response procedures specific to unauthorized CA detection.

Red flags include vendors who cannot describe which CAs they trust, vendors who have never audited their trust stores, vendors who lack automated certificate lifecycle management, and vendors who do not monitor certificate transparency logs. A vendor with a mature PKI posture will have a documented policy, technical enforcement of its approved CA list, and monitoring in place to detect deviations.

Evidence examples

Cross-framework mapping

Related controls

• AU-10 — Non-repudiation: Ensures the integrity of digital signatures and non-repudiation services that depend on the same PKI certificate hierarchy SC-17 governs.
• IA-05 — Authenticator Management: Covers the management of authenticators including PKI-based credentials, complementing SC-17’s certificate policy requirements with broader authenticator lifecycle controls.
• SC-12 — Cryptographic Key Establishment and Management: Addresses the cryptographic key management processes that underpin certificate issuance and the trust anchor hierarchy SC-17 requires organizations to control.

Frequently asked questions

What is NIST SP 800-53 SC-17?

SC-17 is the NIST SP 800-53 control that requires organizations to issue public key certificates under a formal certificate policy and restrict trust stores to only approved trust anchors. It applies to both internal PKI operations and externally obtained certificates, covering any certificate with visibility to organizational systems. Organizations must define which certificate authorities they trust and actively govern what root certificates appear in their certificate stores.

What happens if SC-17 is not implemented?

Without SC-17, trust stores can accumulate unauthorized certificate authorities that your systems treat as fully trusted. An attacker who installs a rogue root certificate can issue valid-looking certificates for any domain, enabling undetectable TLS interception and forged authentication credentials. The absence of a formal certificate policy also means there is no defined process for certificate issuance, renewal, or revocation, increasing the risk of expired certificates causing service outages or security downgrades.

How do you audit SC-17?

Auditing SC-17 starts with verifying that a documented certificate policy exists and defines the approved certificate authorities, trust anchor management procedures, and certificate issuance criteria. Auditors then compare the trust stores across endpoints, servers, and applications against the approved CA list to identify any unauthorized root certificates. Evidence should include automated trust store audit reports, certificate inventory records, and change logs showing that modifications to trust stores follow the documented approval process.

What is a trust anchor in PKI?

A trust anchor is a certificate authority whose trustworthiness is assumed rather than derived from another authority in the certificate hierarchy. In most PKI deployments, root certificates serve as trust anchors because they are self-signed and sit at the top of the certificate chain. SC-17 requires organizations to explicitly approve which trust anchors appear in their certificate stores, because any entity that controls a trusted root CA can issue certificates that your systems will accept as valid.