Self-hosted PKI for NIST SP 800-53 SC-17

The certificate policy is the written document that defines which certificates the CA issues, to whom, for what purposes, with which key sizes, lifetimes and validation steps. SC-17 requires certificates to be issued under a defined certificate policy or obtained from an approved provider, and SP 800-53A lists the certificate policy as an examine object. Your organization owns this document, and the CA configuration must match it. Assessors will check that each certificate profile in the CA traces back to a clause in the policy. Ask your implementation partner to draft it against your system boundary and to tie each profile to a named owner and review date.

The issuing process description explains how a request moves from identity check to signing, including who approves it and how the request is authenticated. SP 800-53A lists the public key issuing process as an examine object, and assessors often pair it with an interview of the staff who run issuance. The CA configuration shows the enforcement: for step-ca, the provisioners (such as ACME, OIDC, JWK or cloud instance identity) define which requesters can obtain which certificates. Ask for a walkthrough from request to issued certificate, with logs from a sample of real issuances.

SC-17 requires that only approved trust anchors appear in organization-managed trust stores. The artifact is a register of approved root and intermediate certificates, with fingerprints, owners and the date each was added or removed. Assessors examine the register and then test a sample of systems to confirm their trust stores match it. Name the team that changes trust stores and the change ticket process that governs them. Ask your partner how trust distribution is automated for Linux hosts, containers and Kubernetes workloads, and how drift is detected.

Assessors review the CA configuration file, the provisioner list and the access controls on administrative functions. In step-ca, the configuration (ca.json) and each provisioner entry define issuance behavior, allowed names, maximum lifetimes and authentication methods. Export these files on a fixed schedule into version control so you can show what changed and when. Ask for evidence that the provisioner list matches the certificate policy and that only named administrators can modify it. If you use OpenBao PKI or FreeIPA Dogtag, the equivalent is the role or profile configuration and the authentication method list.

SC-12 requires that cryptographic keys are established and managed according to defined key management requirements whenever the system uses cryptography, so the CA root and intermediate keys need documented custody. Keep signed ceremony records that name the participants, the witnesses, the hardware used (HSM, cloud KMS or YubiKey, as supported by your CA) and the key generation steps. Store key backup and access records separately from the CA host. Ask your partner to define the key management requirements that SC-12 expects, then map each ceremony to them. Confirm with your HSM or KMS vendor which key custody reports they can export.

Assessors expect a current inventory of issued certificates with subject, issuer, profile, expiry date and owning system, plus records of every revocation with the reason and date. The inventory supports the examine step for the issuing process, and it shows whether certificates stay within the policy's lifetimes. Revocation records show that compromised or retired certificates were withdrawn. Confirm how your CA publishes revocation status (CRL or OCSP, where your CA supports it) and how long those records are retained. Ask your partner to set up a scheduled export and a reconciliation between the inventory and the systems that use the certificates.

Retain logs of every issuance, renewal, revocation, provisioner change and administrative login, with timestamps and the identity of the actor. These logs let the assessor test whether issuance followed the policy in practice, not only on paper. Send CA logs to a central log store that the CA administrators cannot edit, and confirm retention periods with your authorizing official and records team. Your SIEM or log platform should alert on unexpected provisioner changes. Ask your partner which log fields the CA emits and how they are protected in transit and at rest.

Your team can produce most of this evidence if it owns the CA, the trust store process and the change records, but the initial design and the first assessment-ready package usually take specialist time. DeployOpen plans, implements, documents and hardens self-hosted platforms inside your infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports or certifications, and independent assessors make that determination. Most engagements are fixed-scope, with the evidence list agreed in writing before work starts. Ask any partner which artifacts they will deliver, who owns them after handover, and how the package will be kept current.

The main drivers are the size of the certificate estate, the number of certificate authorities, the key storage choice and how much issuance you automate. A small estate with one issuing CA and software-protected keys is far less work than a multi-tier hierarchy with HSM-backed roots, several issuing CAs and automated renewal across many platforms. Costs fall into one-time items (design, policy drafting, key ceremonies, integration and documentation) and recurring items (operating the CA, reviewing certificate policy, monitoring expiry, patching and assessment support). Ask any implementation partner for a quote that separates these, lists each CA and platform in scope, and names who supplies the HSM or cloud KMS and who pays for it.

No duration can be stated without a written scope, because the timeline depends on the systems to be covered, the number of CAs, the state of your existing policies and how quickly your assessor and approvers can review deliverables. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the schedule should come from that document rather than from a generic estimate. Ask for milestones tied to the certificate policy approval, the key ceremony, the first issuance and the evidence package, and confirm which of these depend on your internal review cycles.

The agency has to provide the people and records that only it can supply. That includes named policy owners who can approve a certificate policy and the issuing process, an accurate system inventory showing which components need certificates and which trust stores they use, and access for the independent assessor to examine configurations, logs and procedures. Interviews are part of the assessment method for SC-17, so the people who run issuance and key custody must be available. Confirm these owners and access windows in the statement of work before the design starts.

A capable internal team can run a private PKI if it already operates identity, Linux and certificate tooling and has time to document decisions. The harder parts are usually the root key ceremony, the certificate policy and the evidence package, because the assessor reviews them against SC-17 determination statements and the related SC-12 key management expectations. Teams without prior assessment experience often underestimate the documentation volume. Consider a partner for design review, hardening and evidence preparation even if your staff operates the CA day to day, and write down which tasks each side owns.

SP 800-53B assigns SC-17 to both the moderate and high baselines, so the control itself is the same at either level. The difference lies in how much the assessor expects to see and in how tightly the surrounding controls are tailored for the system's impact level. Under the moderate baseline you should expect the certificate policy and issuing process to be examined and the trust store contents tested. Under the high baseline, the depth of key custody evidence, separation of duties and monitoring is normally greater. Confirm your tailoring decisions and any organization-defined parameter for SC-17 with your authorizing official before design work begins.

SC-17 allows an organization to obtain certificates from an approved service provider instead of issuing them under its own policy, so a SaaS PKI can be part of the answer, but it does not satisfy the control on its own. The approval status of the provider, the certificate policy it operates under, the trust anchors you accept and the evidence you can obtain from it all have to be reviewed for your system. Ask the provider which approvals apply to its service in your authorization boundary, and confirm with your authorizing official how the provider is treated. A self-hosted CA gives you direct control over those trust anchors but moves policy and evidence work onto your team.

Each option carries different documentation work, so compare them against the evidence you must produce:

• step-ca, licensed under Apache-2.0, issues X.509 certificates, supports ACME for renewal and can protect CA keys in HSMs, cloud KMS or YubiKeys. Your team documents provisioner configuration and key protection.
• FreeIPA, licensed under GPL-3.0-or-later, bundles the Dogtag certificate authority with directory and Kerberos services, so policy and identity evidence sit in one system.
• OpenBao PKI, licensed under MPL-2.0, fits teams that already manage secrets with OpenBao and want issuance tied to that platform.

Confirm with each vendor and your assessor which configuration items they will examine, and record the version you deploy, since FreeIPA 4.13.4 fixed two CVEs in July 2026.