Why private PKI for financial services is a different build
A private certificate authority is feasible on open-source platforms for a bank or payments operator, but the design is driven by key custody, audit evidence and duty separation rather than by issuance tooling. The tooling is the easy part. A bank has to show who can create, sign and revoke certificates for internal services, payment links and staff devices, where the CA keys live, and how every issuance is recorded. In practice, the short answer is step-ca for automation, OpenBao PKI for issuance tied to secrets management, and FreeIPA Dogtag for Linux-heavy estates. Which one fits depends on what already runs in the estate, who owns it, and which systems must trust the new hierarchy.
Financial services adds constraints that change the architecture from the start. The root and issuing CA keys usually sit in hardware security modules or a comparable custody model, and the key ceremony, signing rights and backup procedures must be documented well enough for an internal audit or external assessor to test. Certificate issuance for payment links and cardholder-data paths also touches obligations such as the PCI DSS certificate inventory and key management requirements, so the CA must be able to produce a current, exportable list of what it has issued. Confirm with your assessor which systems fall inside the cardholder data environment before you decide how far the inventory must reach.
Separation of duties is the design decision most often left until late. The people who request certificates, the people who approve profiles, the people who hold CA keys and the people who review logs should not be the same group, and the platform must enforce that split through roles, provisioners or auth methods, not through policy documents alone. Ask any implementation partner to show how a single administrator is prevented from issuing a certificate under a privileged profile and then suppressing its audit record. That test, run against your own identity provider and change process, will tell you more about the design than any feature list.
Which regulations shape the PKI design and what each means for the build
This table maps the regulations and frameworks most likely to touch a bank's private CA to the concrete design decisions they force. Read each row as a question to answer before the CA hierarchy is drawn: what the rule asks, where the source sits in the supplied references, and what the build must produce as evidence.
| Regulation or framework | What it asks in plain terms | Build consequence for the CA |
|---|---|---|
| FTC Safeguards Rule (16 CFR 314.4) | Encrypt customer information in transit and at rest, and monitor and log the activity of authorized users, for covered non-bank financial institutions. | Require TLS with a documented certificate profile for every customer-data service, log issuance and revocation events centrally, and keep an inventory tying each certificate to the system it protects. |
| HIPAA Security Rule (45 CFR 164.312), only where health data is handled | Unique user identification, audit controls that record and examine activity in systems holding ePHI, person or entity authentication, and transmission security. | Apply only to a bank's health-related systems, such as employee wellness or benefits platforms. Issue device and service certificates with unique subject names and keep CA audit logs reviewable for those systems. |
| PCI DSS v4.0.1 (active version) | Keep an inventory of trusted keys and certificates that protect cardholder data in transit, and manage key lifecycles under documented procedures. | Build the inventory from CA issuance records plus network scans, assign an owner per certificate, and define key custody for any CA keys that sit inside the cardholder data environment. |
| DORA Article 28 (register and exit strategy) | Maintain a register of all contractual ICT arrangements, and document tested exit strategies for services that support critical or important functions. | If a provider runs the CA or its HSM, list it in the register, and keep a tested plan to move issuing CAs, keys and issued certificate records to another platform. |
| DORA Article 30 (contract terms) | Contracts must state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. | Write CA hosting location, key storage location and data return formats into the managed CA or support contract, and require export of CA configuration, certificate records and revocation data. |
| Swift Customer Security Controls Framework v2026 | Swift users must have their in-scope environment assessed against the controls and attest compliance annually in the KYC-SA application. | Scope the PKI that secures Swift connector and messaging components as in-scope infrastructure, and keep certificate and key inventories ready for the independent assessor. |
| SEC Release 33-8810 (ICFR IT general controls) | Access to programs and data, and changes to them, are example IT general control areas for SOX Section 404 assessments. | Separate CA administrator, certificate approver and auditor roles, record every change to CA policy and templates, and retain approvals so financial reporting controls can be tested. |
How the CA hierarchy and HSM-backed keys change in a bank
A bank's CA hierarchy usually keeps the root CA offline and issues everything else from online issuing CAs, so a compromise of day-to-day issuance does not expose the trust anchor that every other certificate depends on. The root signs only intermediate certificates during planned ceremonies, and the issuing CAs run on networked servers in step-ca, OpenBao PKI or FreeIPA Dogtag, depending on the estate. The private key for each CA is the asset the audit will focus on. step-ca can protect CA keys in an HSM, a cloud KMS or a YubiKey, so the design decision is which custody model the bank's key management policy accepts for each tier. Confirm with the HSM vendor which FIPS 140 validation level and Common Criteria evaluation apply to the specific model and firmware the bank will buy, because those claims belong to the vendor's certificate, not to this page.
Separate issuing CAs by trust domain so that payment link certificates, internal service certificates and staff device certificates each chain to their own intermediate. This matters for revocation and blast radius. If the staff device CA is compromised, the bank can revoke that intermediate and reissue staff certificates without touching payment endpoints or internal service trust. Each issuing CA should have its own signing key in the HSM or KMS, its own certificate profiles and lifetimes, and its own named approvers. Illustrative example: a bank that places its card-acceptance endpoints under a dedicated issuing CA can rotate that CA's key on a planned schedule without re-trusting the staff laptop fleet. Document which trust domain each CA serves, which relying parties must trust it, and how a revocation of that intermediate would propagate.
Document every key ceremony as a controlled procedure: named participants and their roles, the witnessed steps, the hardware used, the script or runbook version, the signed output, and where the key material and backups are stored. Record the ceremony in the same evidence store as the certificate inventory so an assessor can trace a live issuing CA back to the ceremony that created it. Separate the people who can request signing from those who can approve it and from those who hold HSM administrator credentials. Your PKI and key management policies should state these splits, and your auditors will check whether the systems enforce them. Ask any implementation partner to show a sample ceremony record and the HSM role model before scoping the work.
Which open-source platforms fit a financial PKI and why
A bank's private PKI usually combines an issuing CA, a key protection model, and clients that request certificates for services and devices. The options below cover the issuing CA, the secrets platform that can host it, the Linux directory option, and the Kubernetes client, and each one changes who owns keys, how audits are evidenced and what procurement must review.
step-ca for automated issuance
step-ca is Smallstep's open-source online CA for automated issuance and renewal of X.509 and short-lived SSH certificates, licensed under Apache-2.0. It supports ACME, OIDC, cloud instance identity and JWK provisioners, so each issuance path can be tied to a named identity source. For a financial PKI, confirm that the CA signing key is held in an HSM, cloud KMS or YubiKey as your key management policy requires, and test how provisioner configuration is reviewed and logged.
OpenBao PKI with secrets
OpenBao is an MPL-2.0 secrets manager hosted under the OpenSSF, and it can issue certificates alongside key/value secrets, dynamic credentials and encryption as a service. Keeping certificates and secrets on one platform simplifies inventory and access review, but it also concentrates risk, so separate administrative roles for the PKI engine from those for application secrets. Its storage choice matters: PostgreSQL or integrated Raft are the officially supported HA backends, and you should confirm which one your operations team can run and restore.
FreeIPA Dogtag for Linux estates
FreeIPA bundles the Dogtag certificate system with an LDAP directory and Kerberos, which suits banks whose server and workstation identities already live in a Linux directory. Enrollment can follow directory policy, and the directory gives a single place to see which hosts and users hold certificates. Confirm that Dogtag's HSM integration and offline root options meet your key custody rules, and confirm how the directory's replication and recovery procedures are tested before you rely on it for issuance.
cert-manager as the Kubernetes client
cert-manager is the component that requests, renews and stores certificates inside Kubernetes, and it can use ACME, a CA issuer, OpenBao or step-ca as the signing source. It does not replace the CA, so the bank still needs a separate policy for which issuers each namespace may use and for who can change them. Confirm how the issuer credentials are stored, how renewal failures alert the platform team, and how expiring certificates are reported into the inventory that auditors will request.
HashiCorp Vault licensing for procurement
HashiCorp Vault 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which the Open Source Initiative does not treat as an open source license. A bank that requires OSI-approved components in its architecture review should record this before standardizing on Vault, and should check whether its own license policy allows BSL-licensed software in production. Confirm the license terms with the vendor and your legal team, because the choice affects the OpenBao option above.
Deployment constraints by bank environment
In a restricted on-premises data center, the offline root CA and its key ceremony equipment usually sit in a locked, access-logged room or cage that has no route to production networks. Online issuing CAs run on dedicated hosts in a protected zone, and their keys are held in a network HSM or a PKCS#11 device that the bank's key custodians control. Because many internal services can reach only a small set of approved hosts, CRL distribution points and OCSP responders must be placed inside each zone that relies on them, not only in the head office.
- CA and HSM placement: Confirm which zone hosts the issuing CAs and whether the HSM partition is shared with other applications.
- Revocation reachability: Publish CRLs or run OCSP responders in each zone so that relying parties can check status without crossing a firewall.
- Issuing CA availability: For OpenBao PKI, run an active node with standbys on integrated storage (Raft) or PostgreSQL, and place the nodes across failure domains.
- Time and DNS dependencies: Confirm that internal NTP and DNS resolve inside the zone, since certificate validity and revocation checks depend on both.
- Change control: Confirm with the network and compliance teams which firewall changes, key ceremony approvals and evidence retention rules apply to each new distribution point.
Before any design is fixed, ask the network team to map every zone that needs revocation data and ask compliance to confirm how key ceremonies are witnessed and recorded.
In a private cloud, the CA servers run as virtual machines or containers inside a bank-controlled account or tenant, and the CA key can be protected by a cloud KMS or a dedicated HSM service. The design question is how much trust the bank places in the cloud provider's key management, and whether the provider's administrators can reach the key material. Each cloud region or availability zone that hosts an issuing CA should be treated as a separate failure domain, and revocation endpoints should be reachable from every consuming network without exposing the CA itself.
- Key location: Confirm whether the CA key sits in a cloud KMS, a customer-managed HSM or a hardware device, and who holds the administrative roles over it.
- Revocation endpoints: Publish CRLs or OCSP through a load-balanced service that reads from a static location, so that the CA host is never exposed to consuming networks.
- High availability: Run OpenBao with an active node and standbys across at least two zones, and confirm the storage backend's latency and replication behavior.
- Account boundaries: Keep the PKI account separate from application accounts so that workload administrators cannot change issuance policy.
- Egress and private links: Confirm that the KMS and storage endpoints are reached over private connectivity and that the bank's cloud security team approves the route.
Confirm with the cloud and compliance teams how the cloud provider's key management is assessed in the bank's third-party risk process and where key access logs are retained.
Hybrid estates often span an on-premises core, a private cloud and payment network segments that are isolated for cardholder data. The payment segment usually needs its own issuing CA or a separately scoped sub-CA, so that certificates for payment links can be audited and revoked without touching general internal trust. Revocation data must cross the segment boundary in a controlled way, and the team must decide whether the payment zone can reach OCSP or must rely on CRLs published through a one-way transfer.
- Segmented issuance: Issue payment-segment certificates from a sub-CA with its own key, policy and HSM partition, separate from general staff and service CAs.
- Controlled revocation flow: Decide whether the payment zone pulls CRLs through an approved transfer path or queries an OCSP responder placed inside the segment.
- Replicated but separated state: Run OpenBao clusters per trust domain rather than sharing one cluster across the payment boundary.
- Inventory across zones: Feed certificate discovery from every zone into one inventory so that expiry and issuer data are visible to the audit team.
- Connectivity for renewal: Confirm which ACME or API renewal paths may cross into the payment segment and which must be blocked.
Confirm with the network security and payment compliance teams which segment boundaries apply, how revocation traffic is permitted and whether the payment zone's assessor expects a separate PKI scope.
How a bank rolls out a private PKI in phases
The sequence moves from defining which certificates and rules apply to a working, audited issuing hierarchy, so each phase hands the next one a tested and documented output. Banks should expect the early phases to take the most scrutiny from risk, audit and key custody owners.
Scope certificate populations and regulations
The bank's PKI team, application owners and compliance leads list every certificate population in scope: internal service TLS, payment link endpoints, mutual TLS between services, staff device and VPN certificates, and code or document signing. Each population is mapped to the rules that apply to it, such as PCI DSS for cardholder data environments, DORA for ICT services supporting critical functions, or the FTC Safeguards Rule where it applies. The output is a scoped register of populations with owners, regulatory mappings and the systems that will consume certificates. The step is done when security and compliance sign off that no in-scope population is missing.
Design the hierarchy and key custody model
The architecture team defines the CA hierarchy, including the offline root, the issuing CAs by environment or business line, and the trust chains each population will use. It also decides where each CA key is stored, such as an HSM, a cloud KMS or a hardware token, and who may approve key use. The output is a design document covering hierarchy diagrams, key custody rules, certificate profiles and lifetime policy, reviewed against the bank's existing key management standards. Ask the implementation partner to show how the design separates root custody from day-to-day issuance before the design is accepted.
Run the root key ceremony
The root CA is created during a scripted key ceremony with witnesses from security, audit and the business owner, and the event is recorded in full. Key generation takes place inside the approved HSM or hardware boundary, and the root is then taken offline. The output is a signed root certificate, a ceremony record with participants and timestamps, and backup key material stored under dual control. The ceremony is complete when the record is reviewed and filed with the audit evidence set, and the root is confirmed to be offline.
Build the issuing CAs and high availability
Engineers deploy the online issuing CAs, typically step-ca, OpenBao PKI or another platform the design selected, into the bank's chosen environments with keys held in HSM-backed storage. They configure provisioners, revocation distribution, logging and high availability, and test failover between nodes. The output is a running issuing tier with documented configuration, a tested failover result and a runbook for CA outage handling. Confirm the high availability design against the storage backend the platform documents, since supported HA backends differ by product.
Pilot automation on one service family
The team picks a single service family with a clear owner, such as internal web applications behind one ingress, and automates issuance and renewal through ACME or the platform's API. Application owners test trust distribution and renewal without manual steps, and failures are logged and reviewed. The output is a pilot with measured renewal success, a documented onboarding pattern for other teams and a list of application changes required. The pilot is complete when renewals run without manual intervention through at least one full certificate lifetime cycle that the design allows.
Stand up inventory and expiry monitoring
The bank connects the CA issuance logs and network scanners to a central certificate inventory that records owner, issuer, key type, lifetime, location and the system that consumes each certificate. Alerts are set for approaching expiry and for certificates issued outside the approved hierarchy. The output is a live inventory that can be exported for auditors, with a reconciliation report showing coverage against the scoped populations from the first phase. Ask for evidence that the inventory catches certificates that were not issued by the internal CA.
Migrate existing certificates in waves
Teams move certificates from legacy CAs or manually managed certificates to the new hierarchy, wave by wave, starting with the lowest-risk populations and ending with payment-facing and critical services. Each wave includes a cutover plan, a rollback path and trust store updates tested in non-production environments. The output is a migration tracker showing each population's status, the remaining legacy certificates and the retirement date for each legacy CA. The step closes when the inventory shows no unmanaged certificates in the scoped populations or each exception has a documented owner and approval.
Separate duties and sign off audit evidence
The bank assigns distinct roles for CA administration, certificate approval, key custody, audit review and inventory ownership, and confirms that no single person can issue, approve and review the same certificate. Access reviews, change records, ceremony logs and monitoring output are assembled into an evidence pack organized by control. The output is a signed role matrix, a sampled evidence set and a sign-off memo from internal audit or the compliance function. DeployOpen prepares these controls and evidence for independent assessors, who decide whether they meet the bank's obligations.
Evidence auditors and regulators ask for from a private CA
This table lists the evidence a financial institution typically assembles for a private CA, the component that produces each item and the gap teams most often find. Read it as a checklist to confirm with your assessor before the review starts. DeployOpen prepares this evidence, but the auditor, certification body or assessor issues the opinion.
| Evidence item | Producing component | What the assessor checks |
|---|---|---|
| Certificate policy and certification practice statement | Written policy set, versioned in a document repository | Issuance rules, key sizes, lifetimes per certificate type, and that the CA operates as the policy describes |
| Key ceremony records for root and issuing CAs | Ceremony scripts, witness sign-offs, HSM or offline media logs | Who attended, dual control was enforced, and the ceremony followed the approved script |
| HSM key attestation and custody records | HSM vendor attestation output, cloud KMS key policy export | CA private keys were generated and stored inside the HSM, with non-exportable settings confirmed |
| Certificate inventory export | Inventory tooling fed by CA records and network scanners | Every certificate protecting payment links and internal services is listed with owner, expiry and key location |
| Issuance and revocation logs | step-ca logs or OpenBao audit devices, shipped to the SIEM | Each issuance and revocation maps to an authorized requester, a provisioner or auth method and a time stamp |
| Role assignments showing separated PKI duties | Identity provider group exports, OpenBao policies, step-ca provisioner list | Certificate requesters, approvers, key custodians and CA administrators are different people or groups |
| Change records for CA configuration | Ticketing system entries linked to Git commits of CA configuration | Each change to profiles, provisioners or templates was requested, approved and tested before deployment |
| Backup and restore test results | Backup job logs, restore test records, CA database and key backup inventory | Restores were tested on a schedule and the recovered CA issued and revoked certificates correctly |
| Expiry and outage monitoring reports | Expiry monitoring alerts and incident tickets | Expiring certificates were renewed before deadlines and CA outages were recorded and reviewed |
What banks ask before building a private PKI
What drives the cost of a private PKI for a bank?
The largest cost drivers are how CA keys are held, which HSM or cloud KMS option is chosen, how many certificate populations need issuing, how many existing certificates must be migrated, and how much in-house PKI skill already exists. Key custody and HSM choice tend to shape the one-time build, while certificate volume, automation coverage and renewal operations drive what recurs. Ask any partner for a quote that separates hardware or KMS fees, licensing (if any), implementation work per platform, migration work, and ongoing operations, and that states which items the bank pays for directly. DeployOpen does not publish prices; a quote follows from a written scope.
How long does a private PKI build take in a bank?
The timeline is set less by the software than by key ceremonies, change approvals, HSM procurement and the number of systems that must trust the new hierarchy. Plan for a design phase covering hierarchy, lifetimes and key custody, a ceremony phase for root and issuing CAs, then staged onboarding of certificate populations, each with its own change window. Migration from an existing CA usually runs longest because every consumer must be inventoried and re-pointed. No duration applies to every bank, so ask for a schedule in the written scope with named milestones and dependencies.
What does the bank need to provide for a PKI implementation?
The bank typically supplies named architects for the hierarchy and trust model, key custodians who attend ceremonies, network access to the target environment and to the systems that will request certificates, and change windows that match its own governance. It also needs owners for each certificate population, such as ingress, internal APIs, staff devices or payment links, who can confirm endpoints and renewal behavior. Agree these responsibilities in writing so that delays in one team do not appear as delays in the vendor's work.
Can the bank run its PKI internally after handover?
Yes, if the team has the skills and the handover is planned for it. A bank that takes over operations needs staff who can run key ceremonies, issue and revoke certificates, monitor expiry, perform backups and restore tests, and apply upgrades to step-ca, OpenBao or FreeIPA Dogtag, depending on the design. Ask for runbooks, recovery procedures and training as deliverables, and agree a support model for the period after handover. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, so the bank can choose how much to keep in-house.
Do regulators accept open-source PKI software?
Regulators generally assess the controls, evidence and governance around a system rather than its license. Frameworks such as the FTC Safeguards Rule, DORA and PCI DSS ask whether keys are protected, access is controlled, activity is logged and third-party arrangements are documented. Open-source software can meet these expectations when the bank can show key custody, access reviews, change records and tested recovery. Confirm with your own compliance team and auditors which evidence they expect, since DeployOpen prepares controls and evidence for assessments but does not issue audit reports or certifications.
How do you separate PKI duties in a small bank team?
Separate the roles of root key custodian, CA administrator, certificate approver and auditor, so that no single person can create a trusted certificate and also review it. In a small team, use dual control for ceremonies and CA key operations, rotate approvers across roles where possible, and require that audit logs are reviewed by someone outside the issuing function. Where people cannot be separated, compensate with stronger logging, recorded ceremonies and periodic review by an independent party. Document the matrix and test it during the design phase.
How should a bank plan to exit a PKI provider under DORA?
Start with a documented exit strategy and transition plan, which DORA Article 28(8) requires for ICT services that support critical or important functions, and keep the register of contractual arrangements under Article 28(3) current. Make sure the contract states where services and data are processed and covers return of data on termination, as Article 30(2) requires. For PKI specifically, plan how CA private keys, certificate records and revocation data would move, and test the procedure rather than only documenting it. Confirm these requirements with your legal and third-party risk teams.
What to ask an implementation partner before signing
Ask for the root key ceremony method in writing before any scope is agreed. Request the ceremony script, the number and roles of key custodians, how quorum is set, where the ceremony is witnessed and recorded, and how the root key is generated and stored. Ask whether keys are generated inside a hardware security module and what attestation evidence the partner will hand over showing that the key was created in that device. For HSM support, ask which HSM models and firmware versions have been tested with the chosen CA software, who holds the administrator and operator credentials, and how key backup and restore are performed and tested. Confirm the HSM vendor's own certification status with the vendor directly rather than relying on the partner's summary.
Ask how PKI duties are separated and how that separation is enforced in the tooling, not only in the runbook. Request a role matrix covering who can approve a CA policy change, who can sign issuing CA certificates, who can revoke, and who administers the systems that host the keys. Ask for the revocation design in writing: which CRL distribution points and OCSP responders exist, whether they are reachable from restricted network segments, how stapling is handled, and what happens to relying services when the responder is unavailable. Ask how a migration from an existing CA will run, including how trust chains are re-anchored, how overlapping validity periods are managed and how the old CA is retired. Request the certificate lifetime strategy for each class of certificate, with the reasons for each value.
Ask which documents will be delivered at handover so your internal audit and external assessors can test the controls. A useful set includes the certificate policy and certification practice statement, the key ceremony records, the certificate inventory and its update process, issuance and revocation logs, and evidence of access reviews for CA administrators. Request these as examples before signing. For contract terms, ask that the agreement state where services are provided and where data is processed, that advance notice is required for changes to either, and that data return is covered on termination or insolvency, in line with the contract provisions of DORA Article 30(2). Ask for a documented exit plan that covers moving CA keys and issued certificate records to another platform, and check whether your regulator expects that plan to be tested. Finally, ask what post-handover support is available, its response expectations and who performs root-level operations after the project ends.
How DeployOpen scopes and supports a financial PKI
The sequence below takes a bank or payments firm from an unscoped PKI question to a written, fixed-scope plan, a working self-hosted CA, and the evidence an assessor will ask for, with ongoing support available afterward.
Confirm the certificate estate and regulatory scope
DeployOpen starts by working with your security, payments and infrastructure leads to define which systems, payment links, staff devices and internal services need certificates, and which of them fall inside a cardholder data environment or a critical or important ICT function. The client confirms which frameworks apply, such as PCI DSS, DORA or Swift CSCF, because that determines which records must exist. The step closes with a written scope note listing systems in and out of scope, the named owners of each, and the open questions that must be answered before design starts.
Design the CA hierarchy and key custody model
Using the scope note, DeployOpen drafts the certificate authority hierarchy, including where the offline root sits, which issuing CAs step-ca, OpenBao PKI or FreeIPA will run, how HSM or cloud KMS key storage is used, and how separation of duties is enforced between requesting, approving, issuing and revoking. The design also covers certificate profiles, lifetimes and revocation distribution. The output is a written design document that the client's security and risk owners review and sign off before any key is generated.
Document policies, key ceremonies and runbooks
DeployOpen writes the certificate policy, certification practice statement style procedures, key ceremony scripts, and operational runbooks for issuance, renewal, revocation and CA recovery, using the client's own control language. Roles are mapped to named staff and to the access model in the client's identity and privileged access tooling. The step is complete when the client's risk owners have approved the documents and the key ceremony plan has named witnesses and a recorded approval path.
Implement the CA and issuance automation
DeployOpen installs and configures the chosen CA platform inside the client's own cloud accounts, data centers or network segments, sets up HSM or KMS-backed keys, and connects ACME, API or workload-identity enrollment for the systems in scope. Automation is built for each platform where it is needed, and high availability is configured according to the documented backend choice. The step closes when test certificates issue, renew and revoke correctly in a non-production environment and the results are recorded.
Build the certificate inventory and expiry monitoring
DeployOpen connects the CA logs and scanners to a certificate inventory that records owner, system, issuer, key storage, lifetime and trust location for each certificate in scope. Expiry alerts and reporting are configured so the client can show current coverage at any time. The output is an inventory export and a monitoring dashboard or report, together with a written procedure for keeping the inventory current, which the client's compliance team can hand to assessors.
Harden, test and validate the PKI
DeployOpen hardens the CA servers, automation endpoints and admin access, and can run security testing against the CA interfaces, enrollment APIs and the automation pipelines, including attempts to bypass approval steps or obtain unauthorized issuance. Findings are logged, fixed or accepted in writing by the client, and retested. The step is complete when the test report and remediation record are delivered, and the client's owners confirm the residual risk in writing.
Hand over evidence and migrate workloads
DeployOpen migrates in-scope workloads to the new CA in agreed waves, and packages the design, policies, key ceremony records, configuration baselines, inventory exports, test results and change logs into an evidence pack organized by the client's framework mapping. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications, which remain the job of the client's independent auditor, Qualified Security Assessor or certification body. The step closes with a handover session and a signed acceptance of the delivered scope.
Support operations under a retainer
After handover, the client can move operations to its own team or place DeployOpen under an ongoing support retainer covering upgrades, backup and restore checks, responses to certificate incidents, periodic re-testing and assistance with assessor questions. The retainer scope, response expectations and any service levels are written into the agreement before work begins. The client should confirm each of these terms in the written proposal, since no standard service level or duration is set in advance.
