The architectural model

The Cryptographic
Control Plane.

A precise architectural definition, designed to be implementable, auditable, and vendor-neutral — together with an explicit statement of what it does not govern.

Definition

What is a Cryptographic Control Plane?

A Cryptographic Control Plane is a dedicated infrastructure layer that decouples cryptographic policy and lifecycle management from application implementation. Applications express cryptographic intent. Infrastructure governs how cryptographic operations are executed, which algorithms are applied, and how those algorithms evolve over time.

Cryptographic intent (application)

The application calls a service with a Key ID reference and a requested operation — encrypt, sign, verify. It specifies what it needs, never how to do it. No algorithm name, no library import, no cipher selection occurs at the application level.

Cryptographic execution (infrastructure)

The Control Plane resolves the intent against the applicable cryptographic policy and context, selects a permitted algorithm, validates key lifecycle state, and coordinates or performs execution. A governed policy change applies to subsequent operations without requiring an application release solely to implement the cryptographic change.

Intent is not only about algorithms Cryptographic coupling also exists at the representation layer. An application can depend not just on an algorithm or a library, but on the algorithm-specific formats, encodings, parameters and metadata used to represent ciphertext, signatures and keys. Expressing intent therefore includes being freed from those: a Control Plane can offer stable representation models across heterogeneous mechanisms, while still supporting specialized formats or profiles where interoperability demands them.

This is not universal interoperability, and must not be read as such. An external system can process a cryptographic representation only when it supports the algorithms, identifiers, parameters, profiles and extensions that operation used. The architecture separates internal representation stability from external interoperability requirements; it does not collapse them.
Capability areas

Six responsibilities, however they are packaged.

The Control Plane's responsibilities can be understood through six complementary capability areas. These are architectural responsibilities, not a prescribed product decomposition — implementations may organize and deliver them differently, and a conformant one need not expose them as six separate things.

01Cryptographic abstraction
02Policy evaluation
03Crypto-agility
04Key and trust orchestration
05Modernization of existing protection
06Audit and evidence
Scope

What the Control Plane governs — and what it does not.

This boundary is part of the architecture, not a caveat attached to it. The objective is not to route every use of cryptography through a single control mechanism, but to make application and data cryptography independently governable and evolvable.

Primary domain

Application and data cryptography

Cryptographic capabilities whose implementation, policy and lifecycle would otherwise be embedded within, or tightly coupled to, individual applications.

  • Application-level encryption / decryption
  • Digital signatures and verification
  • Cryptographic policy and security strategy
  • Key usage and lifecycle
  • Re-encryption and modernization of protected data
Not replaced

Protocol and transport cryptography

These protocols carry their own negotiation, ephemeral key establishment, session state and cryptographic state machines. They evolve through their own protocols, standards, libraries, platforms and termination infrastructure.

  • TLS
  • QUIC
  • SSH
  • IPsec
Complementary

PKI and digital trust

These services establish and maintain identity and trust relationships. The Control Plane integrates with and consumes them where application and data cryptography depends on them — it does not seek to replace them.

  • Certificate authorities
  • Certificate lifecycle services
  • Trust stores
  • Certificate validation services
Why this matters for posture, not just for scope There is a second boundary alongside the domain one. Representation abstraction does not imply universal interoperability — a stable internal representation across mechanisms is not the same as every external system being able to read it. That separation is deliberate and permanent.

An organization's cryptographic posture may still set requirements for domains the Control Plane does not execute. Governance may establish an organizational requirement for TLS or post-quantum readiness even though the handshake itself remains executed by the relevant protocol implementation. CAPA describes the capabilities required to govern cryptographic evolution across the organization — not a requirement that every cryptographic operation pass through one control mechanism.
Core architectural principle

Centralized Governance, Distributed Trust.

The Control Plane centralizes governance. It does not require cryptographic custody, execution or Roots of Trust to be centralized with it — which is a narrower claim than saying it never performs them.

Applications express cryptographic intent
Business application
Microservice
Data platform
Integration layer
↓   standardized interface · key identifier · requested operation
Cryptographic Control Plane
Policy · lifecycle · algorithm and strategy selection · trust orchestration · modernization · evidence
may also execute directly, through its own cryptographic engines — with key protection anchored to an external Root of Trust
↓   coordinates according to policy, sovereignty and jurisdictional requirements
Trust and execution remain where the organization decides
On-premises HSM Data centre
Cloud KMS Provider A · region 1
Cloud KMS Provider B · region 2
PKI / trust services Identity-to-key bindings
Business-unit domain Separate jurisdiction
Convergence happens at the governance layer, not at the infrastructure layer.
Execution happens wherever policy, key architecture and trust boundaries place it — inside the Control Plane, or in any of the domains below.
Supporting principle

Centralized governance must not become centralized cryptographic risk.

An enterprise may deliberately operate multiple HSMs, multiple KMS platforms, cloud and on-premises infrastructure, different providers, multiple regions, multiple jurisdictions, distinct business-unit trust domains and external trust environments. That distribution is frequently intentional — reflecting sovereignty, resilience, risk isolation, provider independence, jurisdictional requirements or organizational structure. The Control Plane provides a common governance layer across those environments without requiring them to be consolidated.

A consequence worth stating plainly Governance convergence and infrastructure consolidation are separate decisions, and may proceed on different timelines. An application or data domain can become governed by the Control Plane while continuing to use its existing HSM, KMS, key hierarchy or trust domain.
Where cryptographic operations actually run A Control Plane is not limited to policy evaluation and orchestration. It may provide cryptographic execution and key-management capabilities directly, while also coordinating external cryptographic infrastructure. Depending on the architecture and the operation, execution may occur within the Control Plane itself, within an HSM or KMS, or through another specialized cryptographic engine — chosen by policy, key architecture and trust boundary rather than fixed by the architecture.

This does not weaken distributed trust, and it is not a licence to centralize keys. Key material may be generated, managed and used by the Control Plane while its protection remains anchored to an external Root of Trust controlled by the organization. What stays distributed is trust; what converges is governance.
Reference architecture

The enterprise cryptographic stack.

The stack holds two different kinds of thing, and conflating them is the most common way it is misread: layers that participate in the cryptographic execution path, and capabilities that define posture or provide enterprise context without sitting on that path. The lower layers are heterogeneous by design — they are not a single centralized cryptographic backend.

Layer 01Applications & services
The applications, services and systems that process business data and require cryptographic capabilities. In a Control Plane architecture, governed applications express cryptographic intent without embedding algorithm-specific implementation decisions.
Layer 02Integration & API layers
APIs, messaging platforms, middleware, service integration layers and external interfaces. These rely on cryptographic protection for authentication, message integrity, confidentiality and secure service-to-service communication, and may need to interoperate with external ecosystems that impose their own protocols, formats and standards.
Layer 03Cryptographic Control Plane ←
The governance and orchestration layer. It evaluates cryptographic intent against the applicable policy and context and determines how the required capability is fulfilled. Responsibilities include policy enforcement, algorithm and security-strategy selection, key and trust orchestration, lifecycle management, cryptographic modernization, interoperability decisions, and coordination across distributed trust domains. It centralizes governance without requiring cryptographic execution or key custody to be centralized — which does not mean execution occurs exclusively outside it. A Control Plane may execute operations through its own cryptographic engines while relying on external infrastructure for key protection, Roots of Trust, or operations that must remain inside those trust boundaries.
Layer 04Enterprise integration ecosystemcontext, not execution path
The Control Plane is not an isolated security system. It participates in the enterprise technology ecosystem that already governs identity and access, workload and machine identity, PKI and trust services, security operations, SIEM and XDR, logging, metrics, tracing and observability, communication and notification services, and operational tooling. These integrations are not necessarily part of the cryptographic execution path — they provide the surrounding context through which identity, authorization, monitoring, evidence and alerting become part of governed cryptographic operations.
Layer 05Distributed cryptographic trust & execution
These infrastructures perform complementary, non-interchangeable functions. HSMs, KMS platforms, key stores and cryptographic engines provide key protection and cryptographic execution. PKI and related digital trust services establish identity-to-key bindings, certificate chains, validation status and other trust relationships. They may coexist across providers, business units, regions, jurisdictions and independent trust domains; the Control Plane does not require them to be consolidated.
HSMskey protection · execution
Cloud KMSkey protection · execution
On-prem key managementkey protection
Secure key storeskey protection
Cryptographic enginesexecution
PKI & certificate authoritiesidentity-to-key binding
Certificate lifecycle & validationtrust status

Hardware and trusted execution are not drawn as a separate layer. Secure hardware modules, TPMs, enclaves and hardware random number generators provide foundational guarantees within or beneath these infrastructures — embedded in HSMs, cryptographic engines and platforms rather than standing beside them.

Some capabilities sit in more than one place A capability's position in this stack depends on the role it performs in a given operation, not on a fixed slot. PKI is the clearest example: certificate lifecycle, trust services and validation often act as surrounding enterprise capabilities (layer 04), while certificates, trust chains and certificate authorities may participate directly in the cryptographic trust relationship of an operation (layer 05). Both readings are correct, for different operations.
Governed cryptography is not created by replacing existing cryptographic infrastructure with a single centralized system. It emerges by introducing a governance layer capable of coordinating cryptographic behaviour across applications, distributed trust infrastructure, enterprise services and external ecosystems.
Required capabilities

What an implementation must provide.

An implementation of this reference architecture provides all of the following. These are stated as requirements so that they are precise enough to build against — not because anyone administers them as a test.

01

Cryptographic abstraction layer

Applications consume cryptographic services through a standardized interface with no direct algorithm selection or library invocation in application code.

02

Context-aware policy governance

Permitted mechanisms, security levels, key lifecycles and cryptographic constraints are defined through policy — not application code — and enforced across the systems governed through the Control Plane. Multiple policies may coexist and apply according to context.

03

Algorithm and lifecycle transition

For governed applications, supported algorithm and security-strategy transitions — including classical, hybrid and post-quantum strategies — can be executed through policy and lifecycle mechanisms without requiring an application release solely to implement the cryptographic change.

04

Key lifecycle governance

Key generation, rotation, revocation, expiration and audit are governed centrally rather than by individual application teams, according to policy and the capabilities of the underlying key infrastructure. Lifecycle governance is centralized; key custody need not be.

05

Coordination across distributed trust infrastructure

The platform can coordinate cryptographic operations across heterogeneous and distributed HSMs, KMS platforms, key stores and trust infrastructure. A platform that requires all keys or Roots of Trust to reside in a single provider, repository or cryptographic failure domain does not satisfy this requirement.

06

Audit, traceability and evidence

Cryptographic operations performed through the Control Plane generate centralized audit and traceability records providing evidence of governed cryptographic activity, policy enforcement and lifecycle events — without requiring that activity to be reconstructed independently from each onboarded application.

No one certifies these There is no conformance suite, no certification body and no evaluation programme — whether there should be is Open Question 2. An implementation states for itself how it meets each capability, and readers judge that claim on its merits.

These requirements also say nothing about coverage. They describe what a platform provides, not how much of an organization's cryptographic landscape is governed through it — that grows as applications are onboarded, and is the subject of the maturity model.
What becomes possible

When cryptography is decoupled.

Four operational capabilities that become substantially more scalable, governable and repeatable once cryptography is treated as infrastructure.

Algorithm evolution without repeated application change

Without CCP

Identify every application using the algorithm, modify libraries or configurations, validate interoperability, test and coordinate releases. Even a technically straightforward transition becomes a prolonged engineering and change-management programme.

With CCP

A governed application invokes a stable cryptographic capability while algorithm selection, security strategy, policy and lifecycle are managed beneath it. The integration effort establishes a governed boundary once, rather than repeating for every subsequent transition.

Centrally governed policy across systems and environments

Without CCP

Each development team chooses its own algorithms, key sizes and configurations. Crypto sprawl across hundreds of services. Determining whether enterprise standards are actually applied requires inspecting individual systems.

With CCP

Requirements are expressed as centrally governed policies and enforced across governed systems. Central governance does not mean one uniform policy: different policies apply according to data, operation, system, counterparty, jurisdiction, trust domain and interoperability requirement.

Modernizing existing encrypted data without recreating it

Without CCP

Read every record, decrypt, re-encrypt under a new algorithm, write back — a large, error-prone engineering project, and one that may be impossible where the originating application no longer holds the plaintext.

With CCP

Governed mechanisms progressively modernize existing protected data — re-encryption, key rotation, mechanism migration, changes to key protection or trust infrastructure. For large objects, streaming transformation avoids loading the dataset into memory and avoids creating persistent plaintext artifacts.

Authority across distributed trust infrastructure

Without CCP

Governance fragments along infrastructure boundaries. Consistency across multiple HSMs, KMS platforms, providers, regions and jurisdictions requires either consolidation or per-domain duplication of the same decisions.

With CCP

Governance converges without requiring trust domains to be physically consolidated. The organization governs which infrastructure may participate, which policies apply and how capabilities are exercised, while key custody and Roots of Trust remain distributed where appropriate.