Why SSH certificate authority design differs for regulated teams
For a regulated team, the design question is not whether to move off static keys, but which control plane will issue, expire and record SSH access. Static keys in authorized_keys files spread across hosts, and leavers keep working access until someone finds every copy. A short-lived SSH certificate authority ties each login to an identity provider session and a short expiry, so revoking a person removes access without hunting for keys. Three open source options fit different starting points. step-ca is the right first choice for a CA-first design, issuing user and host certificates from OIDC or JWK provisioners that map to your identity provider. OpenBao fits teams that already run secrets infrastructure and want SSH certificates managed beside their other credentials. Teleport fits teams that also need session recording and access requests in one product.
Regulated scope changes the evidence you must produce, not only the mechanics. The HIPAA Security Rule at 45 CFR 164.312 expects unique user identification and audit controls over systems that hold ePHI, and the FTC Safeguards Rule at 16 CFR 314.4 expects multi-factor authentication and logging of authorized user activity for covered financial institutions. A certificate proves who obtained access and when it expired, but it does not by itself record what a session did. Decide early whether you need session recording, approval workflows or dual authorization, because those capabilities move the decision toward Teleport. Confirm with your assessor which records they will request and how long they must be kept.
Teleport's Community Edition carries license limits that matter before you pilot it. Its distributed builds are available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Its single sign-on is limited to GitHub, and access requests happen only through the CLI. Larger organizations should plan for the Enterprise license, which adds Okta, Microsoft Entra ID and OIDC single sign-on and just-in-time access requests. Ask the vendor to confirm current terms in writing, and confirm your own headcount and revenue against the license before you choose the edition.
Which access control and audit rules shape the SSH design
This table maps two US access control and audit rules to concrete SSH certificate design decisions. Read each row as an obligation the organization must be able to evidence, then as the build choice that makes that evidence possible. DeployOpen prepares the controls and evidence, but independent auditors and certification bodies decide whether the requirements are met.
| Obligation | What it asks for in SSH | Build decision | Evidence to prepare |
|---|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i)) | Each person is traceable to their own activity on systems that hold ePHI | Issue user certificates with one principal per person from the identity provider, and forbid shared service accounts for interactive login | Identity-to-principal mapping, list of shared accounts and their retirement records |
| Access control and automatic logoff (45 CFR 164.312(a)) | Access is granted per role and ends when it is no longer needed | Set short certificate lifetimes that expire on their own, and map principals to roles rather than to individual hosts | Certificate lifetime policy, role-to-principal matrix, sample expiry logs |
| Audit controls (45 CFR 164.312(b)) | Activity on systems with ePHI is recorded and examined | Forward CA issuance events and host sshd logs to a central store, and record which certificate and principal opened each session | Issuance log samples, log forwarding configuration, review records |
| Person or entity authentication (45 CFR 164.312(d)) | The system confirms that the person or host is who it claims to be | Require the identity provider login and its MFA before the CA signs a user certificate, and verify host certificates on the client side | Provisioner configuration, MFA policy export, host certificate trust settings |
| Transmission security (45 CFR 164.312(e)) | Data in transit is protected against unauthorized access | Use SSH with certificate-based authentication for all administrative sessions, and disable password logins on managed hosts | sshd configuration baseline, disabled-authentication scan results |
| Multi-factor authentication for any individual (16 CFR 314.4(c)(5)) | MFA applies to anyone accessing an information system, including administrators and vendors | Bind issuance to MFA at the identity provider, and treat break-glass or vendor paths as in scope | MFA enrollment report, list of covered users, exception approvals |
| Encryption in transit and at rest (16 CFR 314.4(c)(3)) | Customer information is encrypted in transit and at rest | Confirm the CA signing keys and the storage backend are encrypted, and that SSH sessions use approved ciphers | Key storage description, storage encryption settings, cipher configuration |
| Monitoring and logging of authorized users (16 CFR 314.4(c)(8)) | Activity of authorized users is monitored and logged | Retain certificate issuance and login logs with time synchronization, and alert on certificates issued outside normal patterns | Retention settings, time source configuration, alert rules and tickets |
How short-lived SSH certificates replace authorized_keys
With a self-hosted SSH certificate authority, the server stops asking whether a specific public key appears in a file on that machine and instead asks whether the certificate was signed by a CA it trusts. A user certificate binds a short-lived public key to one or more *principals*, the names an engineer is allowed to log in as, and carries an expiry time. A host certificate does the same for the server itself, so the client can confirm it is talking to the right machine. Because both sides verify signatures against the CA rather than against lists of keys, the authorized_keys file on each host becomes a trust anchor to configure once, not a registry to maintain. step-ca issues both kinds of SSH certificate, and OpenBao can sign them through its SSH secrets engine, so the choice is mostly about which system already holds your identity and key custody decisions.
Principals are where identity provider groups should meet the SSH layer. Map each principal to a role, such as oncall-db or platform-admin, and issue a certificate only when the login session has passed the identity provider's checks, including multi-factor authentication. Confirm with your identity team which group claims arrive at the CA and whether the mapping lives in the provisioner configuration or in an external policy. Short expiry then does the work that key revocation used to do: when an engineer leaves the group, the next certificate request fails, and any certificate already issued expires within its lifetime. Set that lifetime as a deliberate decision with the security team, and test how long a certificate must live to cover a long incident without forcing re-authentication in the middle of it.
Host certificates remove the trust-on-first-use prompt that teaches engineers to accept unknown fingerprints. Clients are configured to trust the host CA, so a server presenting a valid host certificate is accepted without a prompt, and a server presenting an unknown key is refused. For the on-call engineer, the daily change is that login works from any workstation after a single identity provider sign-in, with no key copying and no stale fingerprint warnings. For the platform team, the work moves to rollout and recovery: distributing the CA public key, renewing host certificates before they expire, and rehearsing what happens when the CA is unreachable. Teams that already use Teleport for session access should confirm how its certificate authority fits alongside an existing step-ca or OpenBao deployment before choosing one of them as the issuer.
step-ca, OpenBao and Teleport: which SSH CA fits which estate
Three open source routes issue short-lived SSH certificates, but they differ in scope. step-ca is a focused certificate authority, OpenBao is a secrets platform that includes SSH issuance, and Teleport is an access platform that brings certificates, login and session recording together. The right choice depends on license terms, how many systems you run, and whether you already operate a secrets platform.
step-ca for focused SSH issuance
step-ca is Smallstep's open-source online CA, licensed under Apache-2.0, and it issues short-lived SSH user and host certificates alongside X.509 certificates. Its provisioners decide who may request a certificate, using OIDC, JWK, ACME or cloud instance identity. Check whether your team will run the CA as its own service, how it is deployed for availability, and where the signing keys live. Use an HSM, cloud KMS or YubiKey for the CA key where your policy requires it, and confirm that the provisioner design matches your identity provider.
OpenBao as one secrets platform
OpenBao is an MPL-2.0 fork of Vault, hosted under the OpenSSF, and it can issue SSH certificates from its SSH secrets engine. This suits an estate that already uses OpenBao for other secrets, certificates or keys, because SSH issuance then shares the same auth methods, audit devices and policies. Confirm the high availability design before you rely on it: integrated storage (Raft) or PostgreSQL are the supported HA backends. Plan for the operational load of a broader platform, since SSH issuance is only one of its functions.
Teleport for access with recording
Teleport combines an identity-aware access proxy, a certificate authority for short-lived certificates and session recording in one binary. It works with OpenSSH clients and servers, so teams can keep existing tools. The Community Edition license applies only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so larger organizations need the Enterprise edition for production use. Session recording is in both editions, while moderated sessions, Device Trust, HSM support and FIPS binaries are Enterprise features.
Confirm the Vault license position
HashiCorp Vault 1.15.0 and later is licensed under the Business Source License 1.1, with IBM named as licensor, and that license is not an OSI-approved open source license. Teams that started with Vault and want an open source replacement should confirm the license terms that apply to their version and deployment before planning a migration. Do not assume that the open source label applies to every Vault release. Ask your legal team to review the license file in the Vault repository and document the decision.
Match the CA to your estate
A single server group with a small set of administrators can often run step-ca with an identity provider and a straightforward host trust model. A mixed estate with many servers, databases, Kubernetes clusters and contractor access usually benefits from a platform that also records sessions and manages approvals. Consider the number of hosts, the directories you already run, how many people need access, and whether auditors expect recorded sessions. Ask each vendor or partner to show the principal mapping and expiry settings for your environment.
Verify the license before you adopt
Each option carries a different license, and the terms affect how you deploy and support the platform. step-ca and OpenBao are open source under Apache-2.0 and MPL-2.0 respectively, while Teleport splits its license across modules and editions. Read the license file that applies to the exact edition and version you plan to run, and record that review with your procurement decision. Confirm with the vendor whether support, upgrades and enterprise features are available for your organization size.
Deployment patterns for data centers, cloud accounts and air-gapped networks
On-premises estates usually keep the CA signing key in a hardware security module, with step-ca or an OpenBao PKI engine running on servers the organization controls. The signing key stays in the HSM, while the online CA handles user and host certificate requests from the identity provider. Because the CA sits on the internal network, the design question is less about reachability and more about how many nodes can sign safely and who holds the administrative keys.
- CA high availability: Run at least two CA instances behind an internal load balancer, sharing the same HSM-protected key material. Confirm with the chosen vendor how step-ca and OpenBao store state and handle failover in your topology.
- Unreachable CA: Certificates already issued keep working until they expire, so short lifetimes set the outage window. Plan the renewal path and monitor how long a host can go without a new certificate.
- Host trust distribution: Push the user CA public key and the host certificate settings through configuration management, such as the SSH daemon's trusted CA setting, and verify the rollout on a sample of hosts.
- Storage and HA choices: OpenBao's storage and HA behavior depends on the backend you select (integrated Raft or PostgreSQL), so confirm supported failover and read scaling for your chosen backend before you commit.
- Key ceremony: Record who can initialize the HSM, rotate the CA key and approve changes to signing policy.
Check whether your HSM model and CA version are supported together, and ask for the documented failover test results.
In cloud accounts, teams typically store CA keys in a managed key service and let the cloud provider's instance identity prove which virtual machine is asking for a host certificate. step-ca supports cloud KMS for protecting CA keys and cloud instance identity provisioners for authorizing requests, which removes the need to hand out long-lived bootstrap secrets to each instance. The trade-off is that the cloud account becomes part of the trust chain, so account administration needs the same scrutiny as the CA itself.
- CA high availability: Deploy CA instances across two availability zones in the same region where the provider and your design allow it, and confirm how the KMS key is replicated or restored.
- Unreachable CA: Hosts that cannot reach the CA during an outage keep their current certificates until expiry. Set alerts on remaining certificate lifetime rather than on CA uptime alone.
- Instance identity provisioners: Scope each provisioner to specific accounts, regions or instance tags so that a compromised workload cannot request certificates for hosts outside its role.
- Host trust distribution: Use machine images or configuration management to install the CA trust settings at boot, and rotate them through the same pipeline used for other host configuration.
- Cloud-specific limits: Confirm which cloud KMS and instance metadata features your provider supports, and document any dependency on the provider's control plane.
Ask your partner to show how account-level access to the KMS key and to the provisioner configuration is logged and reviewed.
Air-gapped enclaves usually have no route to a cloud identity provider, so OIDC login and cloud instance identity are unavailable. Authorization has to rely on provisioners that work offline, such as JWK provisioners backed by keys held in hardware, and on an internal directory or manual approval process for user certificates. Because nothing reaches the CA from outside, every dependency inside the enclave must be planned for, including time sources, storage and the path for moving updates in.
- CA high availability: Replicate the online issuing CA within the enclave, and keep the offline root and the HSM or hardware key tokens under documented custody. Confirm how failover works without external services.
- Unreachable CA: Enclave hosts depend on certificates issued before the outage, so lifetimes need to fit the expected maintenance window. Document the procedure for an emergency re-issue when the CA is back.
- Hardware-backed provisioners: Use JWK provisioners whose private keys sit in hardware tokens, and restrict who can present those tokens. Confirm which token types your CA version supports.
- Host trust distribution: Carry the CA public keys and revocation data in on signed media or through an approved transfer process, and verify fingerprints at each enclave site.
- Upgrades and evidence: Plan how software packages, time synchronization and audit logs move across the boundary, and keep the transfer records as part of the assessment evidence.
Ask for the offline runbook and a test that starts from a cold enclave with no outside connectivity.
Rollout phases and the output of each
The sequence moves a team from scattered authorized_keys files to short-lived user and host certificates in controlled stages, and each stage leaves a record that the next one depends on. Every phase has a named output, so a reviewer can check progress without relying on someone's memory of what was changed.
Inventory existing keys and bastion access
The platform team, with each system owner, lists every host that accepts SSH, every authorized_keys file, every bastion or jump host, and every service account or shared login that holds a static key. Each entry records the owner, the principals that use it, and whether the key is still needed. The output is a key inventory that becomes the baseline for cutover and for the decommissioning check at the end. The step is done when every host in the configuration management or asset inventory has an entry, and unexplained keys are flagged for removal or review.
Integrate the identity provider and set MFA policy
The identity team connects the workforce identity provider to the CA so that a user proves who they are before a certificate is issued. The team maps groups in the directory to SSH principals, defines which roles may request which principals, and sets the multi-factor policy that the sign-in must satisfy. The output is a written access matrix (group, principal, host class, MFA requirement) and a test login that issues a certificate only for an authorized user. Confirm with the chosen CA and identity provider which provisioner types and claim mappings are supported in your version before writing the matrix.
Perform the CA key ceremony and store keys
Two or more named custodians generate the SSH user CA and host CA keys under a written ceremony script, with the steps witnessed and logged. The keys are placed in the storage your security policy requires, such as an HSM, a cloud KMS or a hardware token, and step-ca or OpenBao is configured to use that storage. The output is a signed ceremony record, a key custody register and the CA public keys stored where clients will read them. Confirm which key protection options your chosen CA build supports and whether the custodians' roles meet your separation of duties rules.
Pilot user certificates on non-production hosts
The team configures sshd on a small set of non-production hosts to trust the user CA, sets certificate lifetimes that match the access matrix, and asks a pilot group to log in using certificates only. Engineers test normal logins, scripted jobs that need non-interactive access, expiry behavior, and the audit records written when a certificate is issued and used. The output is a pilot report listing each failure, its fix and the retest result, plus a tested set of sshd settings. The pilot is complete when every pilot user can reach their hosts without a static key and each denied attempt is logged.
Roll out host certificates to servers
Each server requests a host certificate that is signed by the host CA and names the hostnames and addresses it answers to. Clients are configured to trust the host CA, which removes trust-on-first-use prompts and the need to copy host key fingerprints. The output is a register of signed host certificates with serial numbers, names, expiry dates and renewal owners, and a check that a client connecting to each host verifies the certificate. Confirm how host certificate renewal is automated for your server fleet before you rely on it at scale.
Cut over production with a break-glass procedure
The team moves production hosts to certificate login in groups, following the change window and rollback plan agreed with each system owner. Before the first group changes, a break-glass account and its access path are documented, tested and held by named people, with the approval and logging rules for its use. The output is a change record per host group, a tested break-glass runbook, and a sign-off from the service owner that normal access works. Cutover for a group is done when its users log in with certificates and the break-glass path has been exercised and recorded.
Revoke and decommission static keys
After each production group has run on certificates through an agreed period of stable operation, the team removes the static keys from the inventory and deletes them from authorized_keys files, bastion configuration and service accounts. Revocation paths for a lost certificate or a departed user are tested against the runbook. The output is a closed key inventory showing each static key as removed, a revocation runbook that has been exercised, and a final report that the key inventory matches the access matrix. Confirm with your auditors which evidence they expect to see for the removal of static credentials.
Evidence auditors ask for and which component produces it
This table lists the evidence assessors commonly request for an SSH certificate authority and names the component that produces each item. Read it as a checklist to set up before the first assessment, not after. DeployOpen prepares this evidence, while independent auditors assess it.
| Evidence item | Component that produces it | What the reader should confirm |
|---|---|---|
| Written SSH access policy covering who may hold certificates and for which principals | Policy documents maintained by the client, referenced by step-ca or OpenBao provisioner and role settings | Policy names owners, approval paths and the principals each group may request |
| Certificate issuance logs tied to unique user identities | step-ca audit log or OpenBao audit devices, correlated with the identity provider login | Each issued certificate maps to one named person, with no shared service accounts |
| Certificate lifetime settings for user and host certificates | step-ca provisioner and template configuration, or OpenBao SSH secrets engine role TTLs | Configured maximum lifetimes match the written policy and are exported as configuration evidence |
| MFA enforcement records for the login that precedes certificate issuance | Identity provider logs such as Keycloak, authentik, ZITADEL or FreeIPA authentication events | MFA is required at the identity provider, and login events show the factor used |
| Session recordings for administrator access to hosts | Teleport session recording, where Teleport sits in front of SSH nodes | Confirm which edition and features your team needs, and where recordings are stored and retained |
| Removal records for staff who have left | Identity provider deprovisioning events and certificate expiry, with revocation for any retained access paths | Removal happens within the timeline the policy sets, and no static authorized_keys entries remain |
| Key custody documentation for the SSH CA signing key | step-ca key protection settings (HSM, cloud KMS or YubiKey) or OpenBao key storage records | Who can sign, how the key is backed up, and how access to the key is logged |
| Host trust configuration showing hosts present certificates signed by the CA | Host certificate records and sshd configuration distributed by the automation tooling | Each host trusts the CA public key and no legacy host key list is still in use |
What teams ask before replacing static SSH keys
What drives the cost and effort of an SSH certificate authority?
The main drivers are how many identity providers and host platforms need to be wired in, how the CA signing keys are protected, and how far audit logs must flow into your existing monitoring. Each login path to the identity provider, each host platform (Linux distributions, bastions, network appliances) and each sshd configuration adds design and test work. Key protection is a separate decision: step-ca can protect CA keys in HSMs, cloud KMS or YubiKeys, and that choice adds hardware or service costs and integration steps. Software licenses for step-ca (Apache-2.0) and OpenBao (MPL-2.0) carry no license fee, so the recurring cost is mainly operations staff time, infrastructure and support. Ask any partner for a quote that lists identity provider integration, host onboarding, key custody, audit integration and handover as separate line items.
Can our internal team run an SSH certificate authority without a partner?
Yes, many teams can run it internally if they already operate an identity provider, configuration management and a secrets or PKI function. The skills needed are identity federation, CA key handling, sshd and client configuration, and on-call response for signing failures. Teams with a small platform group often find the hardest parts are the first host rollout and the break-glass procedure for when the CA or identity provider is unavailable. A partner can cover design, integration and documentation, then hand over runbooks so your staff operate the system. Before deciding, check whether your team has capacity for the ongoing work of key rotation reviews, certificate lifetime tuning and onboarding new host platforms.
How long does an SSH certificate pilot take?
The length depends on scope, not on the CA software alone. A pilot is usually shaped by how many identity provider flows must work, how many host types are in the first group, and whether change windows exist for sshd changes. A narrow pilot covering one identity provider, one host group and one set of principals is much shorter than a pilot that also covers bastions, database hosts and audit forwarding. No duration is given here because none is supplied for this scope. Ask a partner for a written timeline tied to named deliverables, and confirm which hosts and change windows are included before work starts.
What do we need to provide for an SSH certificate project?
The project needs administrative access to your identity provider so login and group claims can map to SSH principals. It also needs an inventory of hosts, including operating system versions, sshd configuration, bastions and any appliances that cannot run a standard sshd. Change windows must be agreed for hosts where sshd_config changes need a restart or a reload. You should also provide access to your log platform so certificate issuance and login events reach the audit trail, plus named owners for the CA keys and approvals. Missing inventory data is the most common reason for delays, so confirm it in the first week of scoping.
How does the Teleport Community Edition license affect the choice?
Teleport is a different category from a bare CA: it bundles an identity-aware access proxy, a short-lived certificate authority and session recording. Its Community Edition license limits distributed builds to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Larger organizations would need Enterprise, which supports more single sign-on options, Device Trust and HSM support. If you are above those thresholds, step-ca (Apache-2.0) or OpenBao (MPL-2.0) are the licenses to compare first. Have legal review the current license text before choosing, because licensing terms change.
Should we use step-ca or OpenBao for SSH certificates?
Choose based on what else you run. step-ca is Smallstep's open-source CA for automated issuance of X.509 and SSH certificates, with ACME, OIDC, cloud instance identity and JWK provisioners. OpenBao is a secrets manager and fork of Vault that also offers PKI, auth methods such as OIDC and Kerberos, and dynamic secrets. If you already run OpenBao for secrets, extending it for SSH may reduce the number of systems to operate. If your priority is a focused SSH and X.509 CA with direct provisioner control, step-ca is often the simpler fit. Test both against your identity provider and host list before committing.
What happens to SSH access if the CA or identity provider goes down?
Short-lived certificates mean existing sessions and certificates keep working until they expire, but new logins cannot obtain certificates while the CA or identity provider is unavailable. The design should define how long certificates live, how emergency access works, and who can approve a break-glass path. Many teams keep a tightly controlled fallback account with separately stored credentials and audit it closely. Confirm the outage behavior of your chosen CA and the high availability design of its backend, including how OpenBao's integrated storage or PostgreSQL backends behave in your environment, before relying on the design in production.
Does this approach help with audit and access control evidence?
It can help. Certificates carry identity and principal information, and login events can be forwarded to your log platform, giving a clearer link between a person and a session than shared keys. The HIPAA Security Rule at 45 CFR 164.312 asks for unique user identification and audit controls, and the FTC Safeguards Rule at 16 CFR 314.4 asks for multi-factor authentication and logging of authorized user activity. Those requirements apply to your environment as a whole, so SSH certificates are one input. Ask your auditor which evidence they expect, and confirm with your partner that the configuration produces it.
Questions to ask an SSH certificate implementation partner
Start with the CA key. Ask who generates the SSH user CA and host CA keys, where they live (an HSM, a cloud KMS, or a hardware token supported by step-ca), and who holds the quorum or the activation material. Ask for the key ceremony script, the list of people who attend, and the evidence the ceremony leaves behind. Then ask how the partner will rotate the CA keys and how many trusted public keys a host must accept during the overlap. A partner who cannot describe these steps in writing has not designed the trust chain yet.
Next, test identity and MFA. Ask how the identity provider's login and MFA event is carried into the certificate: whether the principal is the unique workforce identity, whether the step-ca OIDC provisioner or the OpenBao JWT/OIDC method is configured to reject accounts without strong MFA, and how the principals and validity period are set per role. Ask how shared or service accounts are handled, since a certificate that names a shared login removes individual accountability. For host trust, ask how known_hosts or host certificates are distributed through configuration management and how host certificate renewal is scheduled.
Then cover failure and oversight. Ask what the break-glass path is when the CA or the identity provider is unavailable, who can invoke it, how it is logged, and when the emergency access is revoked. Ask how certificate issuance and SSH session events reach your SIEM, which fields are forwarded, and who owns the parsing. Ask which license applies to each component, such as Apache-2.0 for step-ca, MPL-2.0 for OpenBao, and the separate terms for any enterprise tier, and whether the partner will confirm each in writing. Finally, ask what ongoing support covers, including upgrades, CA key rotation and incident response, and require a written scope with deliverables and a timeline before any work starts.
How DeployOpen scopes and supports SSH certificate authorities
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For SSH certificate authorities, that means agreeing a written scope for who signs which certificates, how logins map to your identity provider, and how the audit trail is retained before any host trust changes are made.
How we scope
- Inventory existing authorized_keys files, bastion accounts and shared keys across hosts and environments.
- Define user and host certificate types, principals, validity periods and which identity provider groups map to them.
- Agree the written scope, deliverables and timeline before any host trust configuration begins, as all engagements are fixed-scope.
How we build
- Deploy the chosen CA, such as step-ca or OpenBao, with CA keys protected in the storage your scope specifies.
- Configure OIDC-based login, certificate provisioners and sshd trust settings on test hosts, then roll them out in stages.
- Test login, expiry, revocation paths and audit log capture against the agreed scope before production cutover.
How we hand over
- Document the signing workflow, principal mapping, host trust distribution and the break-glass procedure for CA unavailability.
- Provide runbooks for certificate renewal, CA key handling and onboarding or removing users and hosts.
- Deliver evidence of access control and session logging that your internal and external assessors can review.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Plan upgrades of the CA and sshd configuration against the release notes your team confirms with each vendor.
- Confirm with your auditors which evidence they need, since DeployOpen prepares evidence but does not issue audit reports.
