SC-17 PKI certificates: requirements and evidence

What SC-17 public key infrastructure certificates require

An assessor or contract that asks for SC-17 at the moderate or high baseline is asking two things. First, that every public key certificate your systems rely on is either issued under a defined certificate policy or obtained from an approved certificate service provider. Second, that the trust stores your systems use contain only trust anchors (the root and intermediate authorities a system is told to believe) that your organization has approved and manages. The control is short, but it covers a real failure mode: a certificate authority nobody approved, or a root installed by hand years ago, can let an attacker or a misconfigured service impersonate a trusted endpoint without anyone noticing. SP 800-53B assigns SC-17 to the moderate and high baselines, and in Release 5.2.0 it has one organization-defined parameter and no control enhancements. Confirm the parameter wording in the catalog before you draft your system security plan, because the value you set there is what the assessor will test against.

The control is hard in practice because certificate issuance rarely sits in one place. Application teams request certificates from a public provider, platform teams run an internal authority, and a few vendor appliances ship with their own roots. Internal authorities are often undocumented: nobody can say who holds the signing key, which templates are allowed, or what the policy says about lifetimes and revocation. Trust stores are edited by hand, so a root added to one fleet during an incident stays there. A practical first step is an inventory: list every issuing authority, every trust store (operating system bundles, Java keystores, container base images, application-specific stores) and the owner of each. Then write a short certificate policy that names approved issuers, and check that each trust store matches the approved list. Open-source options such as FreeIPA, which includes an integrated certificate authority based on Dogtag, and the PKI secrets engine in OpenBao can host or automate parts of this, but the choice of issuers and the policy remain yours.

Evidence for SC-17 is mostly documents and configuration records: the certificate policy, the list of approved providers and internal authorities, the trust store contents with dated change records, and proof that issuance follows the policy. SP 800-53A assesses the control through two determination statements, and its examine objects include the certificate policy and the public key issuing process, so an assessor will ask to see both the written policy and the real issuance records. Ask your assessor early which trust store locations and which issuing systems they will sample. The cost of meeting SC-17 is mainly staff time to build the inventory, write and approve the policy, and reconcile stores, plus any fees for a commercial provider. Those costs recur whenever a new issuer appears or a store is rebuilt, so tie trust store reviews to your change process. DeployOpen can prepare the inventory, the self-hosted issuance configuration and the evidence set under a written scope. It does not issue assessment reports; an independent assessor does that.

Which certificates and trust stores SC-17 covers in your system

SC-17 applies to the moderate and high baselines, and FedRAMP Rev5 requires it at Classes C and D. Before you write a certificate policy, decide which issuers, certificate types and trust stores fall inside your authorization boundary, and name the team that owns each one, because assessors test each issuer and store separately.

Internal certificate authorities

An internal CA issues certificates for private services, management interfaces and internal APIs that public CAs will not sign. Assessors will expect a documented certificate policy for each internal CA, a named owner, and evidence that the CA's signing keys are protected under SC-12. Confirm which internal CAs exist in your environment, including ones created years ago for a single project that nobody currently maintains.

Public certificate authorities

Public CAs issue certificates for internet-facing endpoints, such as load balancers and public APIs. For SC-17, the organization must either issue under its own certificate policy or obtain certificates from an approved provider, so list every public CA you buy from and record why each one is approved. Renewal dates and domain ownership records belong in the same inventory.

Service and workload certificates

Microservices, databases, message brokers and container workloads each need certificates for mutual TLS and encrypted connections. These are the most numerous certificates in most systems and the ones most often issued by hand. Check whether an automated issuance path exists, who approves it, and how a certificate is revoked when a workload is retired.

Device, user and code signing certificates

Device certificates authenticate endpoints and network equipment, user certificates support smart card or client certificate login, and code signing certificates sign software releases and firmware. Include each type only if it sits inside the boundary. Code signing keys in particular need tight control, because a compromised signing certificate can authorize malicious software.

Third-party and cloud-managed issuers

Cloud provider certificate services, managed load balancer certificates and SaaS vendors that issue certificates on your behalf all act as issuers for your system. Their policies and trust anchors may not match yours, so obtain their certificate practices and confirm in writing who controls the issuing keys. Contract terms, shared responsibility notes and vendor assessment records are the evidence to collect.

Operating system, container and application trust stores

Each operating system, container base image, runtime, browser and application keeps its own list of trusted roots. Anyone who can add a root to one of these stores can intercept traffic that the system believes is protected. Inventory each store the system uses, identify who may modify it, and confirm that only approved trust anchors appear. Configuration management records and image scan output usually provide this evidence.

How an assessor tests SC-17 with examine, interview and test methods

This table maps each part of the SC-17 assessment to the method an assessor uses, the evidence they request and the findings that commonly arise. Read it as a preparation checklist: for each row, confirm that your documents, people and systems can produce the evidence named before the assessor arrives.

Assessment element	What the assessor does	Evidence to have ready	Common findings
Determination statement 1: certificate policy	Examine the certificate policy and confirm it governs how public key certificates are issued or sourced.	A signed certificate policy naming owners, approved issuers, key lengths, validity periods and review dates.	Policy exists but does not describe the CA hierarchy actually in use, or has not been reviewed since the environment changed.
Determination statement 2: approved providers or defined issuance	Examine the issuing process and interview staff to confirm certificates come only from the policy or from an approved service provider.	A list of approved certificate providers or internal CAs, with the request, approval and issuance workflow for a sample of certificates.	Teams obtain certificates from unapproved public or self-signed sources, and the approved list is missing or out of date.
Examine: public key issuing process	Walk through the documented steps for requesting, approving, signing, renewing and revoking certificates.	Workflow diagrams or runbooks, ticket records for issuance and revocation, and CA configuration exports.	Process documents describe manual steps that the tooling bypasses, so actual issuance cannot be traced to an approval.
Interview: certificate owners and CA administrators	Ask who requests certificates, who approves them and how expiry and revocation are handled.	Named roles, a responsibility matrix and sample interview answers that match the written process.	Staff describe different approval paths, or nobody can say who owns a particular internal CA.
Test: trace a sample certificate to its issuer	Select sample certificates in use, then trace each chain to a trust anchor under the approved policy.	Certificate chain exports, issuing CA records and the request ticket for each sampled certificate.	A sampled certificate chains to an intermediate CA that is not documented in the policy.
Test: trust store contents	Inspect organization-managed trust stores on sampled systems and compare each anchor to the approved list.	Trust store inventories, configuration management records and the approval record for each trust anchor.	A store contains an unreviewed or legacy root added during a past project, with no owner or approval recorded.
Test: revocation and renewal handling	Check that a revoked or expired sample certificate is no longer accepted by the systems that rely on it.	Revocation records, CRL or OCSP configuration and logs showing rejected connections after revocation.	Revocation is recorded in the CA but systems keep trusting cached or unreviewed certificates.

Building a certificate policy and issuing process in order

This sequence takes SC-17 from an unwritten practice to a documented certificate policy, an issuing process that follows it, and trust stores that only hold approved anchors. Each step ends with an artifact an assessor can examine.

Inventory certificate authorities and approved providers
Start by listing every place a public key certificate comes from today: internal certificate authorities, cloud-managed certificate services, public certificate authorities used for web-facing endpoints, and any vendor appliance that generates its own certificates. The system owner and security lead confirm which issuers are approved for which systems. The output is a register of issuers with owner, scope and approval status, which becomes the first exhibit an assessor asks for when examining the approved providers referenced in SC-17.
Write the certificate policy
Draft the certificate policy as a controlled document that the organization approves and owns. It should cover the scope of certificates, permitted key types and sizes, maximum lifetimes by certificate class, identity validation before issuance, revocation triggers and procedures, and the role responsible for each decision. Assessors examining SC-17 look specifically for a certificate policy or policies, so this document must be versioned, approved by an accountable owner and reviewed on a stated cycle. Confirm the cryptographic requirements against the controls in SC-12 and SC-13 that your baseline also selects.
Decide internal or external issuance for each use
For each certificate use case, record whether it will be issued by an internal authority, an external public authority, or a managed service. Internal use cases such as service-to-service mutual TLS usually sit with an internal authority. Public-facing web endpoints usually need a publicly trusted authority. Document the reason for each choice and the policy clause it falls under. The output is a use-case matrix that shows, for every certificate class, who issues it and under which approved provider, so that no certificate reaches production through an unlisted path.
Build or configure the issuer
Stand up or configure the chosen issuers so they enforce the policy rather than relying on operators to remember it. For internal authorities, this may mean deploying a certificate authority with its own hierarchy, templates and revocation publication. Open-source options that have been identified as relevant include FreeIPA, which contains an integrated certificate authority based on Dogtag, and OpenBao, whose PKI secrets engine issues short-lived X.509 certificates on request. Confirm the capabilities you need, such as template restrictions, lifetime limits and revocation publication, against the vendor documentation before committing. The output is a configuration record showing that the issuer's templates match the certificate policy.
Establish trust anchor change control for each store
Identify every trust store the organization manages, including operating system stores, application keystores, container base images, and service-specific bundles. For each store, record which trust anchors it holds, who may add or remove one, and what approval and testing happen first. SC-17 requires that only approved trust anchors appear in organization-managed stores, so the change procedure must produce a dated record of each addition or removal. The output is a trust anchor register per store and a change ticket trail that matches it.
Run issuance and revocation through the defined process
Operate the process end to end on real requests: a request enters the defined channel, identity is validated as the policy requires, the issuer applies the approved template, the certificate is delivered and recorded, and revocation is exercised when a key is compromised or a system is retired. Keep the issuance log, approvals, and revocation records together so they can be sampled. Where the organization relies on a provider, retain the provider's contractual and operational commitments alongside the internal records. The output is a set of completed requests and at least one documented revocation, which show the process works in practice.
Assemble the assessment evidence
Gather the evidence an assessor will use to test SC-17: the approved certificate policy, the issuer register, the use-case matrix, issuer configuration exports, trust store inventories and change records, and a sample of issuance and revocation records. Map each artifact to the examine objects named in the SP 800-53A procedure for SC-17. Confirm with your assessor which samples and time windows they expect, since those expectations vary by engagement. The output is an evidence package with an index that points each determination statement to the artifact that supports it.

Evidence that passes SC-17 and how to keep it current

An assessor testing SC-17 wants to see a written certificate policy, a defined set of trusted issuers, and records showing those rules were followed in practice. The cards below cover the artifacts that connect policy to issuance and to the trust stores that clients rely on, and how each one stays current between assessments.

Approved certificate policy

This is the governing document that defines which certificate types the organization issues, who may request them, key lengths and algorithms, validity periods, and who approves exceptions. Keep it under version control with a change history, a named owner and a recorded sign-off for each revision. Schedule a dated review at least annually and after any change to the issuing platform, so the policy an assessor reads matches the process the logs show. Confirm the review interval your own governance requires.

Approved certificate providers

Maintain a register of every authority allowed to issue certificates for the organization, whether that is an internal CA, a self-hosted platform such as FreeIPA with its integrated Dogtag-based CA, or an external commercial provider. For each entry, record the owner, the certificate types it may issue, its trust scope and the date it was approved. Review the register when a provider is added, retired or its configuration changes. Assessors often compare this list against the issuance logs to find certificates from unlisted sources.

Issuance logs and sample records

Issuance logs show who requested each certificate, which authority signed it, the subject names, the validity period and the approval that authorized it. Export and retain these logs on a schedule, and keep a sample of individual certificate records that trace each one back to a request and an approval. Test the trace yourself before an assessment by picking a few certificates at random. Confirm that the log retention period matches your audit log policy.

Trust store inventory and changes

Trust stores hold the anchors that decide which certificates a system accepts. Keep an inventory of every store the organization manages, including operating system bundles, application stores, container images and browser or device policies, with the anchors each one contains. Every addition or removal should carry a change request and an approval. Run a scheduled comparison of stores against the inventory, because an unapproved anchor is the failure SC-17 is written to prevent.

Revocation and expiry reports

Reports on expiring and revoked certificates show that the organization tracks certificate lifecycle rather than discovering problems through outages. Produce a recurring report of certificates nearing expiry, revocations issued with their reasons, and any certificate found outside the approved providers. Store each report with its date and the name of the person who reviewed it. Confirm the lead time your teams need for renewal, then set the report window to match.

Automated issuance workflow records

Where certificates are issued through automation, such as a secrets engine that generates keys and certificates on request, the workflow configuration is itself evidence. OpenBao's PKI secrets engine issues dynamic X.509 certificates, so services no longer generate keys and signing requests by hand. Keep the role definitions, policy files and access rules under change control, and review them with the certificate policy. Confirm that each automated role maps to an approved provider on the register.

What meeting SC-17 costs in money and effort

This table lists each cost component of running SC-17 certificate issuance and trust store control, who is paid for it, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs and no price is given here, so use the drivers to scope a written quote.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Issuer software or licenses	Software vendor or subscription provider, or none for self-hosted open source	Licenses recur if commercial; open-source issuers carry no license fee	Number of issuers and whether a commercial CA or KMS is chosen; self-hosted open source removes license spend but not hosting or staffing
Engineering to build and integrate the issuer	Internal platform team or an implementation partner under a fixed-scope agreement	One-time, with later changes recurring	Number of issuers, integration with existing PKI, automation of enrollment, and hardware or HSM key protection
Certificate policy writing and approvals	Internal security, compliance and legal staff; sometimes outside counsel or consultants	One-time drafting, recurring review	Number of issuing hierarchies, approval layers and whether an existing policy can be reused
Trust store inventory	Internal operations staff; a partner may run discovery scripts	One-time baseline, recurring updates	Number of endpoints, containers, browsers, applications and language runtimes that carry their own trust stores
Trust store reviews and change approvals	Internal security and operations staff	Recurring	Frequency of review set by the organization, number of trust anchors, and how often anchors are added or removed
Evidence upkeep	Internal compliance staff; tooling cost if a commercial evidence platform is used	Recurring	Automation of logs, issuance records and store snapshots versus manual screenshots and spreadsheets
External review of the certificate policy	Independent reviewer or assessor, billed by the engagement	Recurring at each assessment cycle	Policy complexity, number of issuers covered and whether the review is scoped to one system or the whole organization
Auditor sampling and testing	The independent assessor, under its own engagement terms	Recurring at each assessment cycle	Number of certificates and stores sampled, quality of issuance logs, and whether evidence can be produced without manual reconstruction
Quote checklist	Requested from every bidder	Not applicable	Ask for line items per issuer, per store class, per evidence source, and for the assumptions behind each unit of effort

FreeIPA and OpenBao as self-hosted sources of certificates

Organizations meeting SC-17 usually need a certificate source they run themselves, with a defined certificate policy and a short list of trust anchors. The two open-source options below cover different needs: one fits identity-centric environments, the other fits service-to-service certificate issuance.

FreeIPA integrated certificate authority

FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag for issuing and managing certificates. It suits environments where users, hosts and services already sit in one identity domain, so certificate requests can follow the same identity records. For SC-17, check whether its profiles and access rules can express the certificate policy your organization has approved, and whether issuance records can be exported for assessors. Confirm the license terms with your legal team, since this page does not provide legal advice.

OpenBao PKI secrets engine

OpenBao (MPL-2.0) has a PKI secrets engine that issues dynamic X.509 certificates, so services get certificates without someone generating a key and certificate signing request by hand and waiting for a CA to sign it. This matters for SC-17 because issuance follows a configured role instead of ad hoc requests. Confirm which roles, key types and lifetimes your certificate policy permits, and how revocation and audit logs are retained for the assessor.

Issuance records as evidence

Whichever source you use, the assessor will ask who requested each certificate, which profile or role issued it, which trust anchor signed it, and when it was revoked. Both tools can keep this history, but the exact fields and export formats need confirmation in your own deployment. Ask your assessor which records they will sample, and set retention so that sampled periods still exist when the assessment runs.

Policy configuration and role definitions

Your certificate policy is only testable if the configuration matches it. Export profile definitions from FreeIPA or role definitions from OpenBao and compare them line by line with the approved policy, covering allowed names, key sizes, validity periods and approved requesters. Record each difference as a finding in your plan of action and milestones rather than leaving it in the configuration. Have the assessor confirm that the exported configuration is the one in production.

Trust anchors in organization-managed stores

SC-17 also requires that only approved trust anchors appear in the stores your systems use. Neither tool controls the trust stores on every operating system, browser or application in your estate, so you must inventory where roots are installed and remove any that are not approved. Confirm how your chosen tool distributes its root certificate, and whether that distribution path is itself under change control.

Who owns SC-17 work: your team, a partner and the auditor

Your organization owns SC-17 because the certificate policy, the choice of issuers and the list of trusted roots are management decisions that the assessor will hold you to. Someone accountable must sign the policy, approve each certificate authority or external provider, and confirm which trust anchors are allowed into organization-managed trust stores. A partner can draft these documents, but the approval and the signature must come from your side.

Certificate policy: Own the written policy that defines certificate types, key sizes, validity periods, naming, revocation and who may request certificates.
Issuer approval: Decide which internal certificate authority or approved external provider may issue certificates for each system, and record that decision.
Trust anchor approval: Approve every root and intermediate certificate placed in organization-managed trust stores, and review additions and removals on a set schedule.
Evidence sign-off: Review and sign the trust store inventory, issuance logs and policy review records before they go into the system security plan or assessment package.
Operating ownership: Assign named staff to handle renewals, revocations and exceptions after the engagement ends.

Before engaging anyone, confirm internally which person can sign policy and trust decisions, since that person will be the one the assessor interviews.",

Where SC-17 programs usually fall short and how to close the gap

SC-17 is short, but assessors test it against real records: a documented certificate policy, an approved issuing process and a controlled list of trust anchors. The gaps below tend to appear where those records drift from practice. Each card names the gap and the concrete fix an assessor would expect to see.

Undocumented internal certificate authority

Teams often stand up an internal CA for service certificates and never record its existence, owner or scope. SC-17 expects certificates to be issued under a defined certificate policy or from an approved provider, so an unrecorded CA fails before any testing starts. Build an inventory of every issuing CA, including those in FreeIPa or OpenBao PKI engines if you run them, and record each one's owner, purpose and the certificate policy it operates under.

Certificate policy describes a different process

A certificate policy that promises manual approval, key ownership checks or fixed validity periods, while engineers issue certificates through scripts, is a finding in itself. Assessors compare the written policy with the issuing process and its logs. Walk through a recent issuance end to end, then either change the policy to match the real process or change the process to match the policy, and record the decision and approver.

Trust stores edited without approval

Operating system, container and application trust stores often receive added or removed roots through ad hoc commands, configuration management overrides or vendor images. SC-17 requires that only approved trust anchors be present in organization-managed stores. Export the current root lists from each managed store, compare them with the approved list, and route every addition or removal through a change ticket that names the root, its owner and the reason.

Expired or unknown issuers in inventory

Inventories frequently list certificates without the chain that issued them, so an expired intermediate or an unfamiliar root goes unnoticed until a service breaks. Assessors ask how the organization knows which issuers it trusts. Record the issuer, validity dates and chain for each certificate and root in your inventory, and set alerts for approaching expiry so a retired issuer is removed from the trust store before its certificates lapse.

No named owner for each trust store

A trust store with no owner tends to accumulate roots that nobody can justify. Assign one accountable person or team to each organization-managed store, such as the endpoint image, the Kubernetes cluster bundle, and the application keystores. The owner approves changes, reviews the store on a set schedule and signs off the review record. Without that record, an assessor cannot see who controls the trust anchors.

Evidence gathered only on audit day

When the issuing logs, policy approvals and trust store reviews are assembled just before an assessment, the records often show gaps or reconstructed dates. SC-17 evidence is most credible when it accumulates in the normal course of operations. Keep CA issuance logs and change tickets in a system with retention and access controls, schedule a periodic trust store comparison that writes its output to a dated file, and have the owner sign each review so the evidence exists before the assessor asks for it.

SC-17 questions buyers ask before hiring outside help

How much effort does SC-17 take, and does it need outside help?

SC-17 is a single base control with one organization-defined parameter and no enhancements, so the effort is mostly in writing and approving a certificate policy, listing the approved certificate providers and controlling the trust anchors in your certificate stores. Many organizations can do this in-house if they already run a certificate authority or a managed PKI service. Outside help is most useful when the policy must be aligned with an assessor's examine objects, when certificate issuance is spread across many platforms, or when the team lacks time to collect evidence. Your cost is driven by how many issuing sources and trust stores you run, not by the control's wording. Ask any provider for a written scope that lists each store and issuer covered.

What drives the timeline for SC-17 work?

The timeline depends on the number of certificate issuers, the number of trust stores that must be inventoried, and how many systems use certificates from each source. Other factors include whether a certificate policy already exists, how quickly stakeholders can approve it, and whether certificate issuance is automated or manual. Because SC-17 is tested through a small number of determination statements, the assessment side is usually short compared with the preparation. Ask for a schedule tied to named milestones and client dependencies rather than a single overall duration. Confirm the expected duration directly with your provider once the scope is written.

What does the work need from our team?

Expect to supply several people for a limited period. A security owner must approve the certificate policy and the list of approved providers. Platform or infrastructure engineers must provide access to certificate stores, issuing systems and configuration files. Application owners must confirm which services depend on which certificates. Someone accountable for change control must review trust anchor changes before they are made. Ask the provider to list these roles, the decisions each person signs off on, and the systems each person must give access to before work starts.

Can we do SC-17 ourselves without an implementation partner?

Yes, an organization can implement SC-17 with its own staff, because the control asks for a policy, an approved list of issuers and controlled trust stores, and the organization owns its controls. An implementation partner adds value when it prepares systems and evidence, such as exporting trust store contents, documenting issuance workflows and mapping them to the control. It does not issue reports or certificates, and an independent assessor still tests the control. Decide based on your internal capacity and on whether your assessor expects a specific evidence format. Confirm the expected format with your assessor before you start collecting artifacts.

How does SC-17 relate to SC-12, IA-5 and AU-10?

NIST's Release 5.2.0 catalog lists AU-10, IA-5 and SC-12 as related controls to SC-17. SC-12 covers the lifecycle of cryptographic keys, which includes the keys behind certificates. IA-5 covers authenticator management, which includes the credentials and certificates used to authenticate devices and services. AU-10 covers non-repudiation, where digital signatures and certificate validity matter for proving who did what. In practice, one inventory of certificates, keys and issuers can serve all four controls, so plan evidence once and map it to each. Ask your assessor whether they want the shared evidence cross-referenced in your control documentation.

Can an external provider issue a certificate for our system?

An external provider can issue certificates to your system if it is an approved certificate service provider under your certificate policy. SC-17 allows certificates to come either from a defined policy the organization runs or from an approved service provider. The decision to use an external provider, and the decision on which providers are approved, belongs to your organization. The provider issuing the certificate does not make your system compliant or produce an assessment result. Confirm with your assessor that the chosen provider and its practices satisfy the policy you wrote.

What do FedRAMP Class C and Class D change for SC-17?

FedRAMP's Rev5 baselines require SC-17 at Classes C and D, according to the Consolidated Rules for 2026. For a system in scope, this means the requirement applies as a FedRAMP requirement, and the authorization package must show how the control is met. It does not change the substance of SC-17, but it changes what the assessor expects to see in the documentation. Confirm the current class definitions and the exact evidence expectations in the FedRAMP rules and with your 3PAO before you finalize scope.

What should we ask for in a quote for SC-17 work?

Ask for a written scope that lists the certificate issuers, trust stores, systems and applications covered, along with the deliverables: the certificate policy draft, the approved provider list, the trust anchor control procedure and the evidence set. Request the assumptions behind the effort, the client responsibilities, and the assessment support you will receive. Ask what happens if scope grows, how changes are priced, and whether ongoing support is a separate retainer. A clear quote follows from that written scope, and DeployOpen does not publish a price list.

How DeployOpen scopes and prepares SC-17 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the certificate issuance and trust store controls behind SC-17 Public key infrastructure certificates. We prepare the systems and evidence an assessor will examine, while your organization owns the certificate policy and the independent assessor issues any conclusions.

How we scope

Engagements are fixed-scope, with the systems, certificate authorities and trust stores agreed in writing before work starts.
The written scope names which certificate policy documents and issuing processes are in and out of the SC-17 evidence set.
Ongoing support and continuous testing are available as a retainer after the initial scope is delivered.

How we build

We deploy the chosen certificate issuance platform in your environment, such as an internal CA or a dynamic X.509 secrets engine.
We configure organization-managed trust stores so only approved trust anchors are present on each system class.
We test issuance, renewal and trust anchor changes, then record the results against the SC-17 assessment objects.

How we hand over

You receive documented certificate policy templates, issuance procedures and trust store baselines mapped to the SC-17 determination statements.
Evidence packages include configuration exports, issuance logs and change records that an assessor can examine directly.
Your team receives runbooks for issuing, rotating and revoking certificates, so operations continue after the engagement ends.

How we support

Retainers cover upgrades, certificate platform patching and periodic re-checks of trust store contents.
Changes to certificate policy or approved providers can be reviewed and reflected in updated evidence on request.
Your independent auditor or assessor receives the prepared evidence directly from your team, and DeployOpen does not issue any report or certification.