Public Key Infrastructure Certificates

To meet the Public Key Infrastructure certificates requirement, you must either issue public key certificates under your own documented certificate policy or obtain them from an approved certificate service provider, then prove you manage the full certificate lifecycle. Operationalize it by standardizing certificate issuance, inventory, renewal, revocation, and logging across all systems in your FedRAMP Moderate boundary. ¹

Key takeaways:

• You need a written certificate policy plus consistent, auditable certificate lifecycle operations. ¹
• “Approved service provider” is not a vibe; document your approval criteria and procurement/approval evidence. ¹
• Auditors will look for certificate inventory coverage, renewal/revocation controls, and evidence that practice matches policy. ¹

SC-17 looks simple, but teams fail it in the same two ways: (1) they treat certificates as “just TLS,” and (2) they can’t prove control over issuance and lifecycle actions across the authorization boundary. The requirement is explicit: either you issue certificates under an organization-defined certificate policy or you obtain them from an approved provider. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SC-17 into a small set of operational decisions: Who is your certificate authority (internal PKI vs third-party CA)? What is your certificate policy (and how do you enforce it)? Where is your certificate inventory, and can you show timely renewal and revocation? Which teams are accountable for exceptions? The rest is evidence: procedures, configs, logs, and records that show you can prevent or quickly detect expired, mis-issued, weak, or unauthorized certificates in systems that handle federal data.

This page gives requirement-level implementation guidance you can hand to security engineering and platform owners, while keeping it audit-ready for FedRAMP Moderate expectations tied to NIST SP 800-53 Rev. 5. ¹

Regulatory text

Requirement excerpt: “Issue public key certificates under an organization-defined certificate policy or obtain public key certificates from an approved service provider.” ¹

What the operator must do:

• Make an explicit choice for how certificates are sourced: internal issuance under your certificate policy, or external issuance from an approved provider. ¹
• Define and maintain the certificate policy that governs certificate types, issuance rules, allowed cryptography choices, identity proofing, renewal, revocation, and audit logging. ¹
• Implement lifecycle controls and retain evidence that certificates across in-scope systems are issued, managed, and revoked according to that policy. ¹

Plain-English interpretation (what “good” looks like)

You control trust in your environment by controlling certificates. Auditors are not asking whether you “have HTTPS.” They are asking whether your organization can demonstrate governance and operational control over the certificates that secure authentication, encryption in transit, mutual TLS, code signing (if used), internal service identity, and administrative interfaces inside the FedRAMP boundary. ¹

Meeting SC-17 means:

1. A policy exists that tells engineers what is allowed and how to get it approved. ¹
2. Issuance is controlled (either by your CA under that policy, or by an approved provider with defined approval criteria). ¹
3. The lifecycle is managed so certificates don’t expire unexpectedly, aren’t created ad hoc, and can be revoked quickly. ¹
4. Evidence exists to show this is real practice, not shelfware. ¹

Who it applies to

Entity types in scope: Cloud Service Providers and Federal Agencies implementing FedRAMP Moderate aligned controls. ¹

Operational contexts where SC-17 shows up in audits:

• External endpoints: public-facing web apps, APIs, admin consoles, SSO entry points.
• Internal endpoints: service-to-service mTLS, ingress controllers, internal load balancers, message brokers, Kubernetes admission/webhooks, internal admin UIs.
• Identity and access plumbing: certificate-based auth for devices/workloads, VPNs, bastions, privileged access pathways.
• Third party dependencies: managed gateways, CDNs, WAFs, SaaS used inside the boundary that terminate TLS or issue workload identities.

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

Step 1: Declare your certificate sourcing model

Pick one (or a controlled mix with clear boundaries):

• Internal PKI: You run one or more certificate authorities and issue certificates under your certificate policy. ¹
• Approved service provider: You procure certificates from a provider you have formally approved. “Approved” should mean you have documented criteria and a recorded decision (security review, risk acceptance if needed, contract/ordering records). ¹

Deliverable: a short decision record that states which model applies to which certificate types (public TLS, internal TLS, workload identity, code signing if used).

Step 2: Write or update the certificate policy (operator-grade, not academic)

At minimum, your policy should specify:

• Certificate types in use and allowed use cases (server auth, client auth, signing, internal vs external).
• Identity proofing and request approval workflow (who can request; who approves; required ticket fields).
• Allowed trust sources (which CAs are permitted; any prohibited “bring-your-own” CAs).
• Issuance process (tools, systems, required metadata, naming conventions, SAN rules).
• Renewal expectations and ownership (who is responsible for renewals for each system type).
• Revocation triggers and process (key compromise, decommission, role change, mis-issuance).
• Logging and audit requirements (where issuance/renewal/revocation events are recorded and retained).
• Exception handling (who can grant; how long; compensating controls; how exceptions are tracked). ¹

Practical tip: write the policy so it can be tested. If a statement cannot be validated by artifacts (configs, logs, tickets), rewrite it.

Step 3: Stand up a complete certificate inventory for the FedRAMP boundary

You need a living inventory that answers:

• Where is the certificate deployed (system, hostname, environment, boundary)?
• Who owns it (team, app owner, on-call)?
• Who issued it (internal CA name or approved provider)?
• What is its purpose (server auth, mTLS client, etc.)?
• Status info (validity window, upcoming renewal, revocation status where applicable). ¹

Most teams build this by combining:

• Certificate discovery scans (network and configuration repos).
• IaC and secrets manager data (where certs and keys are provisioned).
• CA logs (what was issued and to whom).

Step 4: Implement issuance controls that prevent “shadow certificates”

Operational controls you should enforce:

• Engineers request certificates through a defined workflow (ticket + approval) or an approved automation path (pipeline + policy-as-code guardrails).
• CA access is restricted; private keys are generated and stored in controlled systems.
• Only approved CAs can be used in production trust stores. ¹

If your environment allows developers to spin up ad hoc certificates, you must still show how you detect and address them (discovery + remediation).

Step 5: Automate renewal and build a hard escalation path for expiration risk

Auditors commonly ask what happens when a cert is close to expiration. You should have:

• Renewal automation where feasible (especially for service endpoints and Kubernetes-style workloads).
• Alerting to the owning team and a backup channel (security/platform) if renewal is not completed.
• A defined emergency renewal procedure for production outages.

Keep this grounded in evidence: alert rules, on-call runbooks, and recent renewal tickets.

Step 6: Define revocation and decommission procedures (and prove you’ve used them)

Revocation is where policy becomes real.

• Define triggers: key compromise, service decommission, mis-issuance, unauthorized issuance, role change.
• Define actions: revoke at CA/provider, remove from trust stores where relevant, rotate keys, validate service health.
• Prove timeliness through incident tickets and CA revocation logs. ¹

Step 7: Validate compliance continuously

Add routine checks that catch drift:

• Discovery scan results compared to inventory.
• Certificates issued by unknown CAs flagged.
• Certificates deployed without a valid owner flagged.
• Misconfigurations (wrong SANs, wrong EKUs, expired certs) routed to remediation.

Step 8: Package audit-ready evidence (map policy to practice)

You want a single “SC-17 evidence pack” folder with:

• Certificate policy (current, approved, versioned).
• Inventory export and data dictionary.
• Procedures/runbooks (issuance, renewal, revocation, exception handling).
• Provider approval evidence (if third party CA).
• Samples: recent issuance/renewal/revocation tickets and corresponding CA logs/configs. ¹

Daydream fit (practical, earned): If you struggle to keep approvals, inventories, and evidence synchronized across teams, Daydream can centralize third party approvals and control evidence collection so your “approved provider” decision and lifecycle artifacts stay audit-ready without a quarterly scramble.

Required evidence and artifacts to retain

Use this as your minimum audit binder checklist:

• Certificate policy approved by the right authority (security governance or equivalent). ¹
• Approved provider records (decision memo, security review notes, contract/ordering evidence) if you obtain certificates externally. ¹
• Certificate inventory for all in-scope systems, with ownership and issuer captured. ¹
• CA/provider logs showing issuance, renewal, and revocation events. ¹
• Access control evidence for CA/admin consoles (role definitions, access lists, approvals).
• Runbooks and tickets showing real operational execution (renewals performed, revocations handled, exceptions granted and closed).
• Configuration evidence (trust store configs, load balancer/ingress TLS configs, IaC snippets) tying deployed certs back to approved sources.

Common exam/audit questions and hangups

Expect variants of:

• “Show me your certificate policy and where it is enforced.” ¹
• “How do you ensure only approved CAs issue certificates used in production?” ¹
• “Do you have a complete inventory for the authorization boundary?” ¹
• “Walk me through a renewal and a revocation. Show artifacts.” ¹
• “What’s your process for exceptions or legacy systems that can’t meet the policy?” ¹
• “If you use a third party CA, why is it approved and where is that decision documented?” ¹

Hangups that cause findings:

• Inventory gaps (especially internal services).
• Certificates issued from “random” tooling outside controlled workflows.
• Revocation process exists on paper but no evidence of use.
• Provider is “approved” informally with no written criteria or record.

Frequent implementation mistakes (and how to avoid them)

1. Treating SC-17 as only public TLS. Fix: include internal mTLS and any certificate-based auth inside the boundary in your inventory and policy scope. ¹
2. Policy that cannot be tested. Fix: rewrite requirements into checks (inventory fields, log events, approvals). ¹
3. No ownership mapping. Fix: require every certificate to have an application owner and escalation contact in inventory.
4. Allowing multiple CAs without guardrails. Fix: maintain an allowed-issuers list and block unknown CAs in trust stores and CI/CD checks.
5. Ignoring revocation. Fix: run a tabletop exercise for a key compromise scenario and retain the tickets and logs as proof of operability.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should frame risk in operational terms rather than “case law.”

Practical risk you are controlling with SC-17:

• Unauthorized certificate issuance enables impersonation (services, users, devices).
• Expired certificates cause outages and emergency changes that bypass normal controls.
• Weak or inconsistent certificate governance breaks your chain of trust and complicates incident response. ¹

Practical 30/60/90-day execution plan

First 30 days: Get control of the decision and the scope

• Name the certificate policy owner and the engineering owner for certificate operations.
• Decide internal PKI vs approved provider per certificate type; document the decision. ¹
• Draft/update the certificate policy with testable requirements.
• Start a boundary-scoped inventory with the highest-risk endpoints (external interfaces, admin paths).

By 60 days: Make it operational and measurable

• Implement the request/approval workflow and restrict CA/admin access.
• Stand up certificate discovery and reconcile results to inventory.
• Add renewal alerting and define an escalation path.
• Document revocation procedures and run a dry-run exercise; retain evidence artifacts. ¹

By 90 days: Prove repeatability and reduce audit friction

• Expand inventory coverage to internal services and platform components.
• Add continuous checks (unknown issuers, missing owners, impending expiration).
• Produce the SC-17 evidence pack with sample tickets and corresponding CA/provider logs.
• Fold certificate exceptions into your governance process with time-bound approvals and closure criteria. ¹

Frequently Asked Questions

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

No. SC-17 allows you to issue certificates under your own certificate policy or obtain them from an approved service provider. You still need documented approval and lifecycle evidence either way. ¹

What does “approved service provider” mean in practice?

It means your organization has defined approval criteria and recorded the decision to use that provider, with evidence. Keep the review artifacts and show that issuance comes from that provider for the covered use cases. ¹

Does SC-17 apply to internal service-to-service certificates (mTLS), or only public-facing TLS?

SC-17 is about issuing or obtaining public key certificates under a policy, so internal certificates used for workload identity and mTLS should be governed the same way when they are in scope of your boundary. Your inventory and lifecycle controls should cover them. ¹

What evidence do auditors typically want to see for certificate renewals?

Provide a sample of renewal events tied to tickets or change records, plus CA/provider logs showing the certificate was renewed and deployed. Alerting rules and runbooks help show the process is repeatable. ¹

How do we handle legacy systems that can’t meet our certificate policy?

Use a documented exception process with a named owner, a defined compensating control, and a closure plan. Track exceptions so you can show they are controlled, reviewed, and not permanent by default. ¹

What’s the fastest way to reduce audit pain for SC-17?

Centralize four things: certificate policy, certificate inventory, provider approvals (if third party), and lifecycle evidence (issuance/renewal/revocation logs and tickets). Tools like Daydream can help keep third party approval evidence and audit artifacts organized across teams.

Footnotes

1. NIST Special Publication 800-53 Revision 5