3AM as a multi-PKI control plane: unified issuance across your existing CAs

3AM functions both as a standalone certificate authority — 3AM Mint, built on AWS KMS — and as a control plane over existing CAs. The two relationships compose: 3AM Mint can issue the subordinate CA certificate for HashiCorp Vault PKI, Microsoft AD CS, step-ca, or another CA, anchoring those CAs to a KMS-backed root in your AWS account; and in control-plane mode 3AM also sits between certificate consumers and the backend CAs that fulfil issuance, reachable via ACME, AWS Private CA, the xPKI REST API, or a custom connector. The result is a single issuance API, a single policy engine, and a single observability layer — with 3AM optionally serving as both the trust anchor above the CAs and the control surface in front of them.

This page covers integration architecture and how 3AM differs from a certificate lifecycle management platform. For why 3AM exists and the broader case for control-plane PKI, start at 3AM overview. For how 3AM is deployed into your AWS account, see 3AM deployment: how it works in your AWS account. For detailed comparisons of the CA platforms 3AM integrates with, see the private CA pillar.

What "control plane" actually means in 3AM's case

The term "control plane" is used loosely in the certificate-management market. Most platforms marketed as control planes are architecturally certificate lifecycle management (CLM) tools: they sit above existing CAs and automate discovery, inventory, renewal, and deployment of certificates the CAs have already issued. They are observers and orchestrators of issuance that happens elsewhere.

3AM sits between certificate consumers and the backend CAs. Issuance requests reach 3AM first. Policy — algorithm, key length, validity, subject naming, EKU constraints, attestation requirements, approval workflow — is evaluated and enforced before 3AM forwards an issuance request to whichever backend CA is the right destination for that policy and that consumer. The consumer receives a certificate; the consumer does not know, and does not need to know, which backend CA issued it.

This distinction is operationally consequential. Policy enforced at the issuance gate cannot be bypassed by a consumer who knows the backend CA's API. CLM platforms can detect and remediate non-compliant certificates after issuance; a control plane prevents them from being issued in the first place.

The problem: PKI sprawl across heterogeneous backends

Most enterprises with mature PKI estates do not have one CA. They have several, accumulated over time:

• A Microsoft Active Directory Certificate Services hierarchy for Windows authentication and internal TLS, dating from the directory rollout
• A separate EJBCA or vendor-managed CA for high-assurance use cases that AD CS was deemed unsuitable for
• HashiCorp Vault PKI for short-lived workload certificates, introduced when service mesh or Kubernetes adoption began
• AWS Private CA or Google Certificate Authority Service for one or more cloud-native workloads
• A public CA contract (DigiCert, Sectigo, GlobalSign, Let's Encrypt) for externally-trusted certificates
• Inherited CAs from acquisitions that nobody has been given budget to consolidate

Each backend has its own enrollment protocol, its own access control model, its own audit trail, its own renewal mechanism, and its own operational team. Certificate consumers — application teams, device fleets, automation pipelines — encounter different interfaces depending on which CA happens to serve their use case. Policy is implemented in N different places and drifts. Observability is fragmented across N sets of logs that do not correlate. Renewing a certificate requires knowing which CA issued it, which is a question consumers should not have to answer.

The conventional response is consolidation: pick one CA platform, migrate everything onto it, decommission the rest. Consolidation is rarely completed. The CAs that remain are usually the ones with the most embedded clients, the most political ownership, or the most regulatory baggage — which means the result is often more CAs (the new platform plus the unmigratable legacy) and the same fragmentation the migration was supposed to solve.

What 3AM unifies

In control-plane mode, 3AM provides a single layer for the operational concerns that would otherwise be implemented N times:

• Unified issuance interface. Consumers integrate with 3AM, not with the backend CA. The interface is consistent regardless of which backend ultimately issues the certificate.
• Centralised policy engine. Algorithm, key length, validity, subject and SAN constraints — including SPIFFE-format identity SANs where the backend CA supports them — EKU restrictions, attestation requirements, and approval workflow are defined once and enforced at the issuance gate.
• Routing logic. A single policy declaration determines which backend CA serves which use case — based on the requesting workload, the certificate profile, the trust domain, or any combination.
• Crypto-agility hooks. Algorithm policy is centralised, which means migrations — RSA to ECC, ECC to post-quantum (ML-DSA-65, SLH-DSA-256), or any future transition — happen in one policy change rather than N migrations.
• Aggregated observability. Issuance, renewal, revocation, and policy decisions across every connected CA are visible in one place. Compliance reporting, anomaly detection, and audit are unified rather than reconstructed from N log streams.
• Consistent enrollment protocols. Consumers can use ACME (RFC 8555) with ARI (RFC 9773) for renewal, attestation-based enrollment for device fleets, or mTLS-authenticated REST regardless of which backend CA serves the request.

The backend CAs continue to do what they do. They keep issuing certificates, keep their own audit trails, keep their existing operational teams. What changes is that consumers no longer integrate with each backend separately, and policy can no longer drift between them.

Backend integration mechanisms

3AM connects to backend CAs through four mechanisms. The right one for any given backend depends on what the backend CA exposes; some support more than one, and the integration choice is made during the design review.

The control plane is extensible. A backend AxelSpire has not previously integrated with becomes a connector built during the design and integration engagement; the consumer-facing interface above the connector does not change.

For 3AM Mint — the standalone CA option, a separate path from any of the above — AWS KMS provides the cryptographic operations and 3AM provides the certificate management: profile handling, issuance logic, signing orchestration, audit. The split is analogous to OpenSSL with an external crypto provider: KMS holds and operates the keys, 3AM does everything else. Mint and control-plane mode coexist in the same deployment.

3AM Mint as a root or intermediate for subsidiary CAs

Separate from fronting backend CAs at the issuance interface, 3AM Mint can sit above them in the trust hierarchy. Mint issues the subordinate CA certificate that anchors HashiCorp Vault PKI, Microsoft AD CS, step-ca, or another CA platform; the subsidiary CA continues to handle operational issuance locally while chaining to a KMS-backed root in your AWS account. The root signing key never leaves AWS KMS HSMs, and the subsidiary CA presents the Mint-issued certificate as its issuing CA to relying parties.

The pattern fits the platforms differently:

• HashiCorp Vault PKI. The Vault PKI secrets engine accepts an externally-signed CA certificate. 3AM Mint generates the subordinate's keypair (or signs a CSR Vault produces, depending on whether the subordinate's private key lives in Vault or in KMS), issues the CA certificate, and Vault uses it as the issuer for short-lived leaf certificates it mints locally at full Vault throughput.
• Microsoft AD CS. AD CS can be installed as a subordinate enterprise CA whose certificate is signed by an external root. 3AM Mint issues the subordinate CA certificate; AD CS continues to serve Windows enrollment, autoenrollment, and template-driven issuance against that subordinate. Subsequent template changes, certificate types, and enrollment policies stay inside AD CS.
• step-ca. step-ca accepts an externally-signed intermediate. 3AM Mint signs the intermediate; step-ca runs operationally as before, including ACME flows, with the Mint-issued intermediate as its issuing CA.
• Other CAs (EJBCA, custom). Any CA platform that can be configured with an externally-signed intermediate is a candidate. The mechanism is the same: KMS-backed Mint signs the subordinate's certificate; the subsidiary CA operates normally underneath.

Why this rather than each CA running its own self-generated root: a single high-assurance trust anchor in AWS KMS HSMs, with a single set of access controls, audit logs, and rotation procedures, sitting above heterogeneous operational CAs. Relying parties trust the Mint root; subsidiary CAs can be added, retired, or replaced without changing the trust store on endpoints. The subsidiary CA's day-to-day throughput, latency, and feature surface are unchanged — Vault still issues at Vault speeds, AD CS still does autoenrollment, step-ca still handles ACME — because operational issuance does not pass through Mint at runtime; only the one-time signing of the subordinate certificate does.

This is independent of, and composes with, control-plane mode. A deployment can anchor AD CS as a subordinate under a 3AM Mint root and integrate AD CS as a control-plane backend over the same custom connector — the subsidiary's certificate chains to Mint, while consumers see 3AM's unified issuance interface at the front. The two patterns address different layers: subordinate issuance answers "whose root do endpoints trust", control-plane mode answers "what API do certificate consumers integrate with".

Common backend scenarios

Concrete answers to the question most existing-PKI buyers actually ask, "what does this look like for my CAs":

• Microsoft AD CS. AD CS does not speak ACME and Microsoft has not added it. Integration is via a custom connector that talks to AD CS's native enrollment surface, scoped during the integration engagement. The connector is a known engineering exercise; the variation is in which AD CS templates need to be exposed and how they map to 3AM policy. Additionally, AD CS can be anchored as a subordinate CA to a 3AM Mint-issued parent; see 3AM Mint as a root or intermediate for subsidiary CAs above. The two patterns compose — AD CS can be both anchored under a 3AM root and integrated as a control-plane backend.
• EJBCA. ACME is the standard path. EJBCA has supported ACME for several years. 3AM acts as an ACME client; EJBCA's certificate profiles continue to govern what it will issue. 3AM policy sits above the profile selection.
• HashiCorp Vault PKI. ACME if you are on Vault 1.14 or later. For older Vault deployments, a custom connector against the PKI secrets engine API. Vault PKI is also commonly anchored as a subordinate under 3AM Mint — the Vault PKI secrets engine accepts an externally-signed CA certificate, which means Vault continues to mint short-lived certificates locally at full speed while chaining to a KMS-backed 3AM root. This composes with control-plane integration: 3AM can both issue Vault's signing CA and front it as a backend.
• AWS Private CA. Direct AWS API integration. Cross-account access where Private CA lives in a different account from the 3AM deployment account.
• Google Certificate Authority Service. Custom connector against the Google CAS API.
• step-ca. ACME-native; step-ca exposes ACME by default. Standard ACME integration applies. step-ca also accepts an externally-signed intermediate, which means it can be anchored as a subordinate under 3AM Mint while continuing to handle operational issuance locally, including ACME flows.
• Vendor public CAs (DigiCert, Sectigo, GlobalSign, Let's Encrypt). ACME where the vendor offers it (most do now); custom connector otherwise. This makes 3AM a single internal interface for both private and externally-trusted certificates with consistent renewal automation.
• xPKI deployments. Native REST integration. This is the mechanism behind operator and high-volume device PKI scenarios in AxelSpire's deployment experience.
• Inherited or legacy CAs from acquisitions. Custom connector during the integration engagement. The point of doing this is rarely to keep the legacy CA forever — it is to wrap legacy issuance in the same interface as everything else so the legacy can be retired later without consumer-side migration.

For deeper comparisons of each of the CA platforms above as standalone choices — independent of 3AM — see the private CA pillar.

Throughput and latency: serverless scaling characteristics

3AM runs on AWS Lambda. The control plane, the policy engine, the issuance path, and the integrations to backend CAs all execute as serverless functions rather than as a fleet of long-running CA hosts. Two consequences matter for buyers:

• Throughput is bounded by Lambda concurrency, not by 3AM-internal architecture. Lambda concurrency limits are very high and are configurable per AWS account. There is no fixed ceiling on certificates per second imposed by 3AM itself; horizontal scale is what AWS Lambda already does. This is a structurally different posture from CA platforms that run on persistent infrastructure with a known throughput ceiling per node and require capacity planning, sharding, or active/active replication to scale.
• Latency carries a small serverless penalty. Routing an issuance through Lambda adds several milliseconds compared to a direct in-process call. For the use cases 3AM is built for — TLS issuance, workload identity, device PKI, machine identity at scale — that overhead is not material. For latency-critical use cases at the microsecond level it would be; those are not what 3AM is designed for.

The combination matters for IoT, operator, and high-volume device PKI use cases where issuance and re-issuance volume is bursty and the alternative is provisioning persistent CA capacity for the peak. Serverless inverts the cost model: you pay for the issuances you do, not for the CA capacity you would need if the peak hit.

3AM Mint and control-plane mode coexist

The two modes coexist in the same deployment. A common pattern is:

• 3AM runs in Mint mode (issuing directly via AWS KMS) for new use cases that do not have a legacy backend, particularly workload identity, device PKI, and short-lived certificates where serverless issuance and KMS-backed key custody are the right architecture.
• 3AM runs in control-plane mode over existing AD CS, EJBCA, AWS Private CA, or vendor CAs for use cases where the backend cannot be moved — regulatory, operational, or political — but the issuance, policy, and observability layer should still be unified.

This means consolidation does not have to happen all at once, or ever. New use cases land on Mint. Legacy use cases stay on their existing CA but consume issuance through 3AM. Over time the legacy backends can be retired as their workloads migrate, but the consumer-facing interface does not change when that happens. Migrations become routing-table changes, not consumer-side rewrites.

Enrollment protocols consumers see

Regardless of which backend CA ultimately issues the certificate, consumers integrate with 3AM through one of the standard PKI enrollment interfaces:

• ACME (RFC 8555) with ACME Renewal Information (RFC 9773), for any workload that already speaks ACME — including but not limited to web servers, ingress controllers, and service meshes. ARI support means renewal timing is driven by the CA's signal rather than fixed thresholds, which becomes critical as TLS validity periods compress under CA/B Forum Ballot SC-081v3 (200 → 100 → 47 days).
• Attestation-based enrollment for device fleets and any consumer that can present a hardware-backed attestation. The control plane verifies the attestation against the policy for that device class before issuance proceeds. This is the pattern used in Matter device PKI, IEEE 802.1AR, and operator/IoT deployments at scale.
• mTLS-authenticated REST for automation, CI/CD pipelines, and bespoke integrations.

The protocol is the same whether 3AM issues the certificate directly via KMS (Mint) or routes the request to a backend CA via one of the integration mechanisms above.

How this differs from a certificate lifecycle management platform

3AM and CLM platforms (Keyfactor Command, Venafi TLS Protect Cloud, DigiCert Trust Lifecycle Manager) are architecturally different categories solving overlapping but distinct problems. The honest distinction:

A CLM platform and 3AM are not direct substitutes. An organisation that already runs Keyfactor or Venafi for inventory and renewal automation may keep doing so and add 3AM to unify issuance across heterogeneous backends. An organisation that does not have a CLM platform and is building inbound PKI capability may find that 3AM's control-plane position covers enough of what a CLM does — discovery is unnecessary if 3AM is the issuance source — that a separate CLM is not required. The right answer depends on whether the existing pain is policy drift at issuance (control plane) or sprawl of certificates already in production (CLM), and most enterprises with mature PKI estates have both.

Operational impact

What changes when an existing PKI estate moves into 3AM's control-plane mode:

• Certificate consumers integrate with one endpoint instead of several. For consumers already using ACME, the change is reconfiguring the ACME directory URL. For consumers using vendor-specific APIs, the change is a one-time rewrite to one of the protocols 3AM exposes.
• CA operators continue to operate their CAs but stop fielding ad-hoc consumer-side integration requests. The CA's enrollment protocol is now an internal interface used by 3AM, not a public surface every team has to learn.
• Security and compliance teams see one policy layer and one audit trail instead of N. Reporting on "what was issued, by whom, against which policy, and was it compliant" becomes a single query.
• Workload teams can adopt new enrollment patterns — ACME with ARI, attestation — without each backend CA having to support them natively, because 3AM mediates.
• Crypto-agility migrations — an algorithm policy change, the addition of a post-quantum algorithm, the deprecation of an older curve — happen in one place. Consumers experience the migration as a policy update; backends see the requests they would have seen anyway.

Frequently asked questions

Does 3AM replace our existing CAs?
No, not unless you choose to. In control-plane mode, 3AM sits in front of the CAs you already operate. Backend CAs continue to issue certificates; 3AM provides the unified interface, policy, and observability. You can decommission backends over time as their workloads migrate, but you do not have to.

How does 3AM integrate with Microsoft AD CS specifically?
AD CS does not speak ACME — Microsoft never added ACME support — so the integration is via a custom connector that talks to AD CS's native enrollment surface. AxelSpire builds the connector during the integration engagement; the variation between deployments is in which AD CS templates are exposed and how they map to 3AM policy, not in whether AD CS can be integrated. See AD CS as a private CA for AD CS-specific detail.

Can 3AM Mint act as a root or intermediate CA for Vault PKI, AD CS, or step-ca?
Yes. 3AM Mint, backed by AWS KMS, can issue the subordinate CA certificate that anchors HashiCorp Vault PKI, Microsoft AD CS, step-ca, or another CA platform. The subsidiary CA continues to handle operational issuance locally — Vault keeps minting short-lived certificates, AD CS keeps serving Windows enrollment, step-ca keeps fielding ACME — while chaining to a KMS-backed root in your AWS account. See 3AM Mint as a root or intermediate for subsidiary CAs above. This is independent of control-plane mode; the two patterns compose.

Why anchor a subsidiary CA to 3AM Mint instead of using each CA's own root?
To consolidate trust anchors. With a 3AM Mint-issued root or intermediate above subsidiary CAs, the high-assurance root key lives in AWS KMS HSMs under a single set of access controls and audit logs, while each subsidiary CA continues to operate its own day-to-day issuance. Relying parties trust one root; the operational CAs underneath can be added, retired, or rotated without changing the trust store on endpoints.

Does 3AM support SPIFFE workload identity?
3AM supports SPIFFE-format identity SANs in policy. Where the backend CA supports issuance of certificates with SPIFFE-named SANs, 3AM validates the SPIFFE identity of the requester against the issuance policy at the gate. SPIFFE is treated as a SAN format and identity scheme that the policy engine evaluates, not as a separate enrollment protocol.

Can 3AM front a public CA like DigiCert or Sectigo?
Yes. Public CAs that expose ACME — most major commercial CAs do now — are integrated as ACME backends. Public CAs that only offer proprietary REST APIs are integrated through a custom connector. Either way, the result is a single internal interface for both private and externally-trusted certificates, with renewal automation and policy enforcement consistent across both.

What's the throughput and latency profile?
3AM runs on AWS Lambda. Throughput scales with Lambda concurrency, which is high and configurable — there is no fixed certificates-per-second ceiling imposed by 3AM itself. Latency carries a small serverless overhead of several milliseconds per issuance, which is not material for the use cases 3AM is built for (TLS, workload identity, device PKI, machine identity at scale). The trade-off is the inverse of persistent CA infrastructure: you pay for the issuances you do, not for the peak capacity you would need if your peak hit.

What happens to existing certificates already issued by the backend CAs?
They continue to operate normally — they were issued by the backend, are trusted because of the backend, and will be renewed when 3AM's policy schedules renewal through the same backend. 3AM does not invalidate existing certificates and does not require them to be re-issued. Migration is at the policy and routing layer, not the certificate layer.

Is 3AM's control-plane mode only for AWS-hosted backends?
No. 3AM itself runs in your AWS account (see 3AM deployment), but the backend CAs it integrates with run wherever they already run — on-premises AD CS forests, self-hosted EJBCA, Vault clusters in any environment, vendor SaaS, or other clouds.

How does 3AM handle CRL and OCSP for certificates issued through backends?
Revocation status comes from whichever party is authoritative for the certificate. For a certificate that 3AM Mint issued directly via AWS KMS, 3AM provides revocation. For a certificate issued by a backend CA, the backend CA's CRL or OCSP is authoritative — 3AM does not duplicate or override the backend's revocation infrastructure. Aggregated revocation reporting across backends is part of the unified observability layer.

What about Matter, IEEE 802.1AR, or other device PKI use cases with attestation requirements?
Attestation-based enrollment is one of the protocols 3AM exposes. The control plane verifies hardware attestation against policy before issuance, regardless of whether the issuance is fulfilled by Mint or routed to a backend with the appropriate trust anchors. Operator and IoT deployments — including high-volume environments with embedded clients such as those using libCertifier — are part of AxelSpire's deployment experience.

Can we run 3AM as a control plane only — never as 3AM Mint?
Yes. The deployment creates the AWS KMS infrastructure for Mint by default, but you are not obligated to use it. A control-plane-only deployment routes every issuance to a backend CA. The reverse is also possible: Mint only, no backend integrations.

Next steps

For how 3AM runs in your AWS account, including the vendor access model and onboarding timeline, see 3AM deployment: how it works in your AWS account. For 3AM's compliance and audit posture, see 3AM compliance: audit, retention, and framework mapping. For the higher-level positioning of why 3AM exists, return to 3AM overview.

The integration design for each backend CA depends on the specifics of the existing deployment, which is the kind of question best answered against your environment rather than in the abstract. The fastest path is Ask Axel for architecture-specific questions, or contact us for a design-review conversation with the AxelSpire team.

Related Resources

About AxelSpire and 3AM

AxelSpire is a B2B PKI consultancy and product company founded by Dan Cvrcek, with roughly a decade of PKI architecture across financial services and high-volume internet/operator environments and post-doctoral research at the University of Cambridge. AxelSpire's core product, 3AM (AxelSpire Automated Management), is a serverless certificate authority and multi-PKI control plane built on AWS KMS. AxelSpire operates in the US, UK, and EU, with additional regions on request.

Authored by Dan Cvrcek (AxelSpire). AxelSpire is a vendor-neutral PKI and certificate lifecycle management consultancy.