SC-17 Public Key Infrastructure Certificates

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Moderate, High	Organization	None

Related controls: AU-10, IA-5, SC-12

Control statement

• a. Issue public key certificates under an [Assignment: organization-defined certificate policy] or obtain public key certificates from an approved service provider; and
• b. Include only approved trust anchors in trust stores or certificate stores managed by the organization.

NIST discussion

Public key infrastructure (PKI) certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates.

Assessment objectives (SP 800-53A)

Objectives and methods for SC-17

Determine if:

• SC-17a. public key certificates are issued under [Assignment: organization-defined certificate policy] , or public key certificates are obtained from an approved service provider;
• SC-17b. only approved trust anchors are included in trust stores or certificate stores managed by the organization.

Examine: System and communications protection policy; procedures addressing public key infrastructure certificates; public key certificate policy or policies; public key issuing process; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities; organizational personnel with responsibilities for issuing public key certificates; service providers.

Test: Mechanisms supporting and/or implementing the management of public key infrastructure certificates.

Policy statement

• The Chief Information Security Officer shall ensure public key certificates are issued under Fill in: a certificate policy for issuing public key certificates Typical: the organization’s certificate policy, or obtained from an approved service provider. (SC-17a)
• The System owner shall include only approved trust anchors in trust stores or certificate stores the organization manages. (SC-17b)

From the System and Communications Protection Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SC-17 asks you to do two things. Issue public key certificates under a certificate policy you define, or get them from an approved service provider. And put only approved trust anchors, the root certificates your systems trust, into the trust stores you manage. NIST’s discussion says this covers certificates seen outside the organization and certificates used inside systems, such as for application-specific time services. SC-17 is in the Moderate and High baselines, not Low.

Common implementations. Internet-facing services use certificates from a public certificate authority, which is the approved service provider, usually issued and renewed automatically by the load balancer, content delivery network or cloud certificate service. Internal services, devices and workloads get certificates from an internal certificate authority run under the organization’s certificate policy, often a cloud private certificate authority or a directory-integrated one. The certificate policy says who may request certificates, how the requester is checked, which key types and lifetimes are allowed, and how certificates are revoked. Trust stores on managed devices, servers and container images come from a managed baseline: the operating system or browser vendor’s root program, plus the organization’s own roots, with roots removed where the organization has decided not to trust them.

The encryption and key management standard puts SC-17 into practice in its certificates section: certificates issued under the certificate policy or obtained from an approved provider, approved trust anchors only, a certificate inventory with owners and expiry dates, warnings before expiry, automatic renewal, and revocation at once when a private key is compromised. It is the same section the SC-12 guidance points to for trust stores. NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management (June 2020), is NIST’s practice guide to running certificates at scale.

Organization-defined parameters. Typical value, from the System and Communications Protection policy, which your organization may set differently:

Parameter	Typical value
Certificate policy	The organization’s certificate policy

The policy names the certificate policy rather than repeating it, so write that document if you run an internal certificate authority, and say in it which certificate authorities count as approved service providers. If you run none and use only public and cloud provider certificates, say so; the approved provider list then carries SC-17a.

Evidence assessors ask for.

• The certificate policy, and the list of approved certificate authorities and service providers
• The certificate inventory: subject, issuer, owner, where it is installed and expiry date
• A sample of certificates from production endpoints, traced to an approved issuer (a TLS scan does this quickly)
• The approved trust anchor list, and the configuration that sets trust stores on servers, devices and container images
• The renewal and expiry alerting setup, and a record of a revoked certificate if one was compromised
• The system security plan’s description of which certificates the system uses and who issues them

Inheritance. The internal certificate authority and the trust store baseline are usually common controls, run by the key management function. A cloud provider’s certificate service is inherited for the certificates it issues and renews. The system owns the certificates on its own endpoints and any trust store it ships, such as in an application or container image, so SC-17 is usually a hybrid control. Record the split in the system security plan, where the SC decision worksheet’s question on who issues certificates and which certificate authorities systems trust is answered.

Common findings.

• An expired certificate in production, or no inventory to show when certificates expire and who owns them.
• Self-signed certificates on internal services, with clients set to accept any certificate (also an SC-8 finding).
• Application or container trust stores that add roots nobody approved, or that bundle an old copy of a vendor root list.
• No written certificate policy for an internal certificate authority that issues certificates to servers and devices.

Enhancements in the Moderate baseline. SC-17 has no enhancements.

Federal systems (as of October 2026). FIPS 201-3 (January 2022) requires certificate authorities that issue certificates for PIV credentials to participate in the hierarchical PKI for the Common Policy managed by the Federal PKI Management Authority, and the certificates to be issued under the X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework (sections 5.1 and 5.2). That covers PIV certificates, which the agency’s PIV issuer or an approved PKI service provider supplies. Systems that accept PIV validate the certificate path to a trusted source, and FIPS 201-3 says path validation should specify which certificate policies are trusted (section 6.2.3.1), so the Federal PKI root is among the approved trust anchors of any system that meets IA-2(12). FIPS 201-3 does not set the policy for other certificates, such as TLS server certificates.

Artifacts

• Encryption and Key Management Standard
• System and Communications Protection Decision Worksheet
• System and Communications Protection Policy