SC-17 Public Key Infrastructure Certificates has two requirements. Issue public key certificates under a defined certificate policy, or obtain them from an approved service provider. And include only approved trust anchors in the trust stores or certificate stores that you manage.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from, so check which parts your customer or auditor actually expects.
The guidance sets the scope broadly: certificates visible outside your systems, and certificates used inside them, such as those for application specific time services. A trust anchor is an authoritative source, such as a certificate authority, whose trustworthiness is assumed instead of derived. A root certificate is the usual example, and a trust store is the list of trusted roots.
What it means in practice
Two questions. Where do your certificates come from, and what does your infrastructure choose to trust?
On the first, you either run your own certificate authority under a written policy, or you buy certificates from a provider you have approved. Both are acceptable. What is not acceptable is a free for all in which any engineer pulls a certificate from wherever is quickest and nobody knows the full list.
On the second, every operating system, browser, container image and application runtime ships with a set of trusted roots. SC-17 asks you to manage the stores you control and keep only approved anchors in them. In practice that means checking custom roots installed on servers and laptops, such as those added by a proxy, a legacy appliance or an old project.
Evidence to collect
- The certificate policy or standard that says who may issue certificates and for which uses.
- The list of approved certificate providers and the date of approval.
- An inventory of certificates, with owner, issuer, expiry and where they are deployed.
- Trust store configuration for managed servers, containers and endpoints, plus any custom roots with a reason for each.
- Automated expiry monitoring and renewal records.
- Private CA documentation if you run one: key protection, issuance approval and revocation process.
- A change record for any addition to a trust store.
Common gaps
The classic failure is an expired certificate that takes a service down. Close behind is no inventory at all. Others:
- Wildcard certificates copied to many hosts, so one leak compromises all of them.
- Self signed certificates in production because someone needed it quickly.
- Custom root certificates added to laptops or build images years ago and never reviewed.
- Private CA keys stored on a shared server with weak access control.
- No revocation process, so a lost key cannot be dealt with quickly.
- Certificates used for internal services, such as message brokers, outside the inventory because they are not internet facing.
How to implement it
Write a one page certificate standard. Name the approved issuers, the key sizes and lifetimes you accept, who can request certificates and how they are approved. Short lifetimes with automated renewal reduce both outage and exposure.
Build the inventory. Public certificates are easy to discover from certificate transparency logs and external scans. Internal ones need scans of your own networks and a look at secrets stores, load balancers and service meshes. Record owners so an expiry has someone to call.
Audit trust stores next. List custom roots on a sample of servers, containers and laptops. For each, record why it is there, or remove it. Add a check to your image build so that unexpected roots fail the pipeline.
Automate monitoring. Alert at 30, 14 and 7 days to expiry and track the alert through to renewal. If you run a private CA, protect its keys with a hardware module or managed key service, and keep issuance logs.
Revisit the process every year, and after any incident involving a certificate.
Continuous checks matter more here than for most controls, since certificates expire on a schedule you cannot negotiate. The walkthrough below shows how ongoing monitoring surfaces drift before it becomes an outage.
An example of the gap an auditor will probe. A company lists twelve public certificates, all renewed automatically. But a scan of its internal network finds forty more, issued by a private authority that a former engineer set up, with no documented owner and several expiring within a month. The fix is not complicated. Add the private authority to the standard, assign owners, and bring those certificates into the same renewal workflow.
Trust stores deserve the same scrutiny. A security appliance that inspects traffic often installs its own root on every laptop, which is acceptable if approved and recorded, and a risk if nobody remembers it. Keep a list of custom roots and a reason for each.
Also think about the build pipeline. Container base images and language runtimes carry their own trust stores. If you copy extra roots into an image to make a test pass, they can ship to production unnoticed. A check in the build that compares the root list against an approved baseline is cheap and catches this.
When an auditor asks for evidence, give them the standard, the inventory export with owners and expiry dates, a sample trust store listing and the alert history. Together they show a process, not a one time cleanup.
Try it yourself
Certificates expire on their own schedule. This demo shows how continuous checks turn a surprise into a ticket.
Click through it at your own pace, or open it full screen.
Quick check
Do I need my own certificate authority?
No. The control allows approved service providers. You do need a policy and an approved list.
What is a trust anchor?
A certificate authority whose trust is assumed, such as a root certificate. Trust stores list them, and SC-17 asks you to keep only approved ones.
