Public Key Infrastructure Certificates SC-17

System and Communications Protection · Moderate baseline ✗ Not implemented

Status — program-wide

What references this control

No risks name this control in their Framework field yet.

No policies reference it yet.

Link a risk or policy to this control

Attaching adds SC-17 to the item's Framework field; the ✨ AI button suggests the best match. You can also edit the Framework field on a risk / policy directly.

Source: NIST SP 800-53 Rev.5, System and Communications Protection family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

SC-17 (Public Key Infrastructure Certificates) is about managing the certificates and trust anchors your systems rely on. PKI (Public Key Infrastructure) is the system of certificates, keys, and authorities that lets machines prove who they are and set up encrypted connections. The control has two parts: issue certificates under a written certificate policy (or obtain them from an approved provider), and keep only approved trust anchors in the stores your organization manages. A trust anchor is a Certificate Authority (CA) — an issuer your system trusts by default, at the top of a chain of trust. It is a Moderate-baseline control.

What good looks like

Get certificates from a named, approved source — a public Certificate Authority (CA) or your own internal CA run under a written policy — not ad-hoc self-signed files.
Keep the system trust store to only the roots you actually need; every extra trusted root is another way in.
Remove or distrust any Certificate Authority you do not recognize or no longer use.
Track expiry dates so certificates are renewed before they lapse and break services.
Protect private keys with tight file permissions — they are as sensitive as passwords.

Framework mapping

How to move it toward Implemented

List the trust anchors your system trusts today (trust list, or inspect /etc/ssl/certs and /usr/share/ca-certificates) and review the list against what you actually need.
To distrust a Certificate Authority, remove or disable its file and run update-ca-certificates (Debian or Ubuntu) or update-ca-trust (Red Hat family) to rebuild the trust store.
Add only approved internal roots via /usr/local/share/ca-certificates/ then update-ca-certificates, and write down where each one came from.
Inventory your server certificates and their expiry (openssl x509 -enddate -noout -in <cert>), saved as a dated file alongside your one-page certificate policy.
Attach that trust-store review and certificate policy as hardening evidence on the asset, naming SC-17 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.