SC-17: Public Key Infrastructure Certificates

To meet the sc-17: public key infrastructure certificates requirement, you must ensure every public key certificate used for authentication, encryption, or signing is either issued under your approved PKI policy/practice statement or obtained from an approved certificate service provider, with documented governance and evidence. Operationalize SC-17 by standardizing certificate issuance, inventory, lifecycle management, and third-party approval.

Key takeaways:

• Standardize where certificates come from: your governed PKI or an approved provider ¹.
• Control the lifecycle: request, issuance, installation, renewal, revocation, and monitoring all need a defined procedure and owner.
• Audit readiness depends on evidence: inventory, approvals, configs, logs, and proof of renewal/revocation execution.

SC-17 sits in the “System and Communications Protection” family and is a control examiners use to test whether you treat certificates as governed security assets rather than ad hoc configuration items. The requirement is simple on paper: issue certificates under your defined PKI governance or obtain them from an approved provider ¹. In practice, teams fail SC-17 for predictable reasons: no authoritative certificate inventory, multiple unmanaged certificate sources, unclear approval rules for external certificate authorities (CAs), inconsistent renewal practices, and weak revocation hygiene.

A CCO or GRC lead typically needs two outcomes fast: (1) a decision on “what counts as approved” for certificate issuance and procurement, and (2) a repeatable operational process that produces assessment-grade evidence. This page gives you requirement-level implementation guidance: who SC-17 applies to, what to build, how to run it, what artifacts to keep, and where audits get stuck. It’s written to help you assign ownership, define the procedure, and stand up recurring evidence without turning your PKI into a science project.

Regulatory text

Control requirement (excerpt): “Issue public key certificates under an {{ insert: param, sc-17_odp }} or obtain public key certificates from an approved service provider; and” ¹.

Operator interpretation (plain English)

You must control the source of truth for certificates. Every certificate in use must be traceable to:

1. Your governed PKI (issued under your documented certificate policy/practice), or
2. An approved external certificate provider (a third party you have formally authorized to issue certificates for your environment).

“Under an {{ insert: param, sc-17_odp }}” is a parameterized placeholder in the catalog. For implementation, treat it as: your documented PKI governance (policy + procedures + roles + technical controls) that dictates how certificates are issued and managed ¹.

Who it applies to

Entities

• Federal information systems and contractor systems handling federal data adopting NIST SP 800-53 controls as security requirements ¹.

Operational context (where SC-17 shows up)

SC-17 applies anywhere certificates are used to establish trust, including:

• TLS certificates for public-facing and internal services (web apps, APIs, service meshes).
• Device certificates (endpoint management, VPN, Wi-Fi 802.1X, IoT/OT gateways).
• Code signing certificates (software releases, scripts, container signing).
• Client certificates (mutual TLS, admin access, privileged tooling).
• S/MIME or document signing (if used).

If you have multiple teams generating certificates independently (DevOps, IT, network, product engineering), SC-17 is a governance control: it forces you to make certificate issuance and procurement consistent.

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

Step 1: Name the control owner and define scope

• Assign a PKI program owner (often Security Engineering, IAM, or Infrastructure) and a GRC control owner responsible for evidence.
• Define which certificate uses are in scope (server auth, client auth, signing) and which environments (prod first, then non-prod).

Practical tip: Examiners look for a single accountable function even if operations are distributed.

Step 2: Decide your “approved issuance paths”

Create an explicit decision record covering:

• Internal issuance: enterprise CA, cloud private CA, or managed internal PKI you operate.
• External issuance: public CA(s) and managed certificate services you approve.

Document approval criteria for external providers (third party due diligence, contractual requirements, operational controls you need). SC-17 does not prescribe the criteria, but it requires that providers be “approved” and that issuance is governed ¹.

Step 3: Publish a certificate policy and operating procedure

Minimum content to operationalize SC-17:

• Allowed certificate sources (internal CA names, external providers by legal entity/service).
• Allowed key algorithms and minimum key sizes (set your standard; don’t scatter this across teams).
• Identity proofing rules for certificate requests (who can request what, and how approval works).
• Validity period standards and renewal triggers.
• Revocation triggers (termination, key compromise, hostname/service retirement).
• Logging requirements for issuance and revocation events.
• Exception process (who can approve an off-standard certificate and for how long).

Output artifact: “PKI / Certificate Management Standard” plus a runbook.

Step 4: Build and maintain a certificate inventory (authoritative list)

Create a system of record for:

• Certificate subject/SANs, issuing CA, serial number, thumbprint, validity dates.
• Where deployed (service name, hostnames, clusters, load balancers).
• Owner (team), environment (prod/non-prod), renewal mechanism (manual/automated).
• Source path (internal PKI vs approved provider).

Evidence expectation: An auditor will ask you to prove you know what certificates exist and where they came from.

Step 5: Implement lifecycle controls (issuance → renewal → revocation)

Operationalize with repeatable workflows:

• Request workflow: ticket or portal with required fields and approvals.
• Issuance workflow: automated where possible; restricted issuance permissions; templates/profiles.
• Deployment workflow: secure private key handling, secrets storage, rotation mechanism.
• Renewal workflow: monitored expiry with defined renewal owner; automation for high-volume systems.
• Revocation workflow: immediate revocation path; confirm revocation publication; remove from endpoints.

Where teams use ACME, managed certificate services, or load balancer automation, document the configuration and show it is constrained to approved CAs/providers.

Step 6: Constrain certificate issuance technically

Policy without enforcement fails in audits. Common technical guardrails:

• Restrict who can create/approve certificate profiles.
• Restrict which CAs can issue which template types (server vs client vs signing).
• Block outbound issuance paths to unapproved CAs (where feasible via network controls or enterprise tooling).
• For cloud environments, restrict IAM permissions to request certificates from managed services.

Step 7: Monitor and review

Set a recurring review cadence for:

• New certificate sources detected (unknown issuers).
• Certificates nearing expiration.
• Revocation events and failed renewals.
• Provider list review (approved third parties and services).

If you use Daydream to manage control execution, map SC-17 to a named control owner, a documented implementation procedure, and a recurring evidence checklist so evidence collection becomes routine rather than a scramble ¹.

Required evidence and artifacts to retain

Keep artifacts that prove both design (the rule) and operation (you follow it):

Governance artifacts

• PKI/certificate management policy and standard.
• “Approved certificate service provider” list with approval record (risk review, procurement approval, security sign-off).
• Roles and responsibilities (RACI) for certificate requests, approvals, revocations.

Operational artifacts

• Certificate inventory export (authoritative list) with ownership fields.
• Sample of certificate requests and approvals (tickets/portal logs).
• CA configuration screenshots/exports: templates/profiles, issuance permissions.
• Logs showing issuance, renewal, and revocation events (from CA, certificate manager, or SIEM).
• Evidence of periodic review (meeting notes, attestation, or report sign-off).

Technical validation artifacts

• Spot-check evidence: presented certificate chains for key services showing issuer is internal CA or approved provider.
• Proof of monitoring: expiry alerts, dashboards, or scheduled reports.

Common exam/audit questions and hangups

1. “Show me your approved certificate sources.” Auditors want a list and the approval basis ¹.
2. “How do you prevent teams from using random public CAs?” If your answer is “policy,” expect a follow-up on enforcement.
3. “Where is your certificate inventory, and who owns each certificate?” Missing owners is a common hangup.
4. “What happens when an employee leaves or a key is compromised?” They want to see revocation steps and evidence the process ran.
5. “Prove renewal works.” They will sample certificates that were renewed and ask for the trail.

Frequent implementation mistakes and how to avoid them

• Mistake: Treating certificates as ‘IT config’ with no governance. Fix: publish a certificate standard tied to approved issuance paths ¹.
• Mistake: No authoritative inventory. Fix: make inventory a control requirement; require owners for every certificate.
• Mistake: Multiple unmanaged issuance tools. Fix: consolidate or formally approve each tool/provider; block everything else.
• Mistake: Manual renewals with no accountability. Fix: assign renewals to service owners and require monitoring alerts.
• Mistake: Revocation is theoretical. Fix: run a tabletop on certificate compromise and retain the run record.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, SC-17 failures increase the likelihood of outages (expired certs), trust failures (unknown issuers), and incident scope growth (slow revocation after compromise). For federal and contractor environments, weak certificate governance also becomes an assessment finding because it undermines authentication and encrypted communications expectations in NIST-aligned programs ².

Practical 30/60/90-day execution plan

First 30 days (stabilize governance and visibility)

• Assign SC-17 control owner(s) and publish the “approved issuance paths” decision.
• Draft and approve the certificate management standard and exception process.
• Produce a first-pass certificate inventory from scanners, cloud certificate managers, load balancers, and known PKI systems.
• Identify any certificates issued by unknown/unapproved CAs and open remediation tickets.

By 60 days (make it operational)

• Implement request/approval workflow for new certificates.
• Tighten CA permissions and template/profile governance.
• Stand up expiry monitoring and ownership-based alert routing.
• Formalize approved third-party certificate providers and retain approval evidence.

By 90 days (prove repeatable operation)

• Run an internal audit sample: trace a set of certificates from inventory to issuance source, approval, deployment, and renewal.
• Test revocation workflow with a controlled scenario and retain logs and approvals.
• Convert SC-17 into recurring evidence tasks (inventory export, provider review, issuance/revocation samples) so you can pass assessments without rebuilding the story each time.

Frequently Asked Questions

Do we have to run our own internal CA to satisfy SC-17?

No. SC-17 allows you to obtain certificates from an approved service provider instead of issuing them internally ¹. You still need documented approval and operational evidence.

What does “approved service provider” mean in practice?

It means you have a documented decision and governance record that the third party is authorized to issue certificates for your systems ¹. Treat it like any other third-party security approval: defined scope, accountable approver, retained artifacts.

Are internally generated self-signed certificates allowed?

SC-17 expects issuance under your PKI governance or from an approved provider ¹. If you use self-signed certs, document them as an exception with compensating controls and a plan to replace them where trust needs to extend beyond a single host.

How do we operationalize SC-17 in Kubernetes and service-mesh environments?

Define which component issues workload certificates (internal PKI, mesh CA, or managed service) and make it an approved issuance path. Then inventory issuers, constrain who can change the issuer configuration, and retain evidence from cluster configs and certificate chain samples.

What evidence is the fastest path to assessment readiness?

An approved provider list, a certificate management standard, an inventory with owners, and a small set of traceable samples that show issuance/renewal/revocation happened under that standard. Map those artifacts to SC-17 so you can reproduce them on demand ¹.

We buy certificates through a cloud provider’s managed certificate service. Is that “approved”?

It can be, if you formally approve that service as a certificate source and document the IAM and configuration controls that restrict who can request and deploy certificates. Keep the approval record and operational logs as evidence ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5