The framework
Five foundational pillars.
Together these pillars enable the operation of a Cryptographic Control Plane capable of supporting continuous cryptographic evolution. They are complementary: centralized governance does not require centralized trust; agility does not remove the need to modernize historical data; sovereignty does not eliminate interoperability requirements.
Pillar 01
Crypto-Agility
Crypto-agility is the ability to transition between cryptographic algorithms, mechanisms and security strategies without requiring changes to application code, application releases, or disruption to business operations for systems that have been brought under governed cryptographic infrastructure.
It enables organizations to respond rapidly to algorithmic vulnerabilities, emerging standards, regulatory requirements and evolving threat models without initiating application development, testing, certification, change-management or deployment cycles. It supports transitions across classical, hybrid and post-quantum cryptography while maintaining operational continuity.
The architectural objective is to transform subsequent cryptographic transitions from application engineering projects into governed infrastructure and policy operations.
Core principle
Cryptographic change without application change.
What this pillar means
Change without code
Algorithms, mechanisms, security strategies and supported cryptographic representations evolve without requiring repeated application changes or releases.
Respond rapidly
Vulnerabilities, standards, regulatory requirements and threat changes are absorbed through governed infrastructure.
Classical → hybrid → PQC
Cryptographic generations coexist and transition while business operations continue.
Capability, not project
Cryptographic evolution becomes an architectural capability rather than a recurring engineering effort.
Boundary
This applies to applications
once governed through the abstraction and Control Plane model. It does not imply that arbitrary legacy applications can change cryptography before being onboarded. Onboarding is real work; what changes is the economics of every transition after it.
The same scoping applies to representation: a stable internal representation across mechanisms
does not imply universal interoperability — an external system can read a representation only when it supports that operation's algorithms, identifiers, parameters and profiles. See the
scope boundary.
CAPA in practice
Responding to an algorithm vulnerability
A critical application relies on a cryptographic algorithm that is found to be vulnerable or no longer acceptable. In a traditional architecture, replacing it may require code changes, regression testing, security validation, change approvals and a new application release. With crypto-agility, the cryptographic strategy can be changed through governed infrastructure and policy while the application continues operating without modification or redeployment.
Transitioning to post-quantum cryptography
An organization needs to move from classical cryptography to hybrid classical–post-quantum mechanisms and, eventually, to fully post-quantum cryptography. Rather than treating each application as an independent migration project, the organization can evolve the cryptographic strategy through the Control Plane, allowing governed applications to transition without embedding new algorithm dependencies into their code.
Evolving cryptographic strategy without an application release
A security team decides to strengthen the cryptographic posture by changing an algorithm family, security level or cryptographic strategy, even though no immediate vulnerability exists. Instead of initiating a new software development and release cycle, the organization implements the change through cryptographic policy. Cryptographic evolution becomes an infrastructure governance activity rather than an application engineering project.
A practical test
Can the cryptographic strategy change without requiring an application change or release?
Pillar 02
Cryptographic Sovereignty
Cryptographic sovereignty is the ability of an organization to retain ultimate authority and control over its cryptographic trust, cryptographic choices, and the use of cryptographic capabilities — regardless of where its data, infrastructure or business processes operate.
It is not merely "owning your keys", and it is not BYOK.
Core principle
Retain control of cryptographic trust, choice, and authority wherever your data operates.
What this pillar means
Control where trust resides
Keys and Roots of Trust remain across the HSMs, KMS platforms, providers, regions and domains chosen by the organization.
Preserve cryptographic choice
External interoperability requirements do not dictate the organization's entire internal cryptographic posture.
Control cryptographic authority
The organization governs who may exercise cryptographic operations, under what conditions, and for how long.
Distribute trust, keep governance
Central governance does not require centralized custody or a single cryptographic failure domain.
A major implication
Sovereignty does not require centralizing keys or trust infrastructure. Organizations may deliberately distribute keys and Roots of Trust across multiple HSMs, KMS platforms, providers, environments, regions or organizational domains to preserve autonomy, isolate risk, improve resilience, or satisfy jurisdictional and operational requirements. Centralized governance should not create unnecessary concentration of cryptographic dependency.
CAPA in practice
Retaining control of the Root of Trust
An organization deliberately distributes cryptographic keys and Roots of Trust across multiple HSMs, KMS platforms, cloud providers, on-premises environments, regions or organizational domains. This distribution may reflect resilience, risk isolation, jurisdictional, operational or business requirements. Cryptographic sovereignty allows the organization to govern these trust domains coherently without requiring their consolidation into a single key repository, infrastructure provider or cryptographic failure domain.
Maintaining revocable cryptographic authority over third parties
A financial institution must provide sensitive encrypted information to an external service provider for processing. Instead of transferring a long-lived private key that gives the provider persistent decryption capability, the organization grants governed authorization to perform only the required cryptographic operations. That authority can be constrained by identity, data scope, purpose, time or policy — and revoked when the business relationship changes or ends.
Preserving cryptographic choice across trust domains
An organization determines that one cryptographic strategy best reflects its internal security and trust requirements, while a customer, partner or external ecosystem requires a different standard for interoperability. The organization can satisfy the external requirement for that interaction without making it the universal standard for its internal environment. Interoperability is maintained without surrendering cryptographic choice.
A practical test
Can the organization govern policy across all its trust domains without moving keys, and revoke a third party's cryptographic authority without re-encrypting the data?
Pillar 03
Frictionless Modernization
Frictionless modernization is the ability to evolve the cryptographic protection of existing data and systems without requiring the applications that originally produced that data to recreate, reprocess or re-encrypt it.
Its centre is not application migration. Organizations may possess data encrypted years earlier whose original applications have changed, been retired, or no longer retain the original plaintext. Cryptographic protection should be capable of evolving independently from the applications that created the data.
Modernization can include re-encryption, key rotation, migration between algorithms, migration between cryptographic mechanisms, migration of key protection, changes in trust infrastructure, correction of long-lived key dependencies, and modernization of historical protected data. For large datasets, streaming cryptographic transformation is an important implementation mechanism.
Core principle
Modernize the cryptography protecting your data, without recreating the data or rewriting the applications.
What this pillar means
Modernize existing protection
Historical encrypted data evolves even when the originating application has changed or disappeared.
No persistent plaintext exposure
Transformations are performed without creating persistent plaintext intermediate artifacts.
Break long-lived key dependencies
Existing data is moved away from obsolete keys, key structures or protection mechanisms.
Independent from applications
Cryptographic protection evolves according to data lifetime rather than application lifecycle.
A precise security claim
These transformations should be performed without creating persistent plaintext exposure or artifacts. This is not a claim that plaintext mathematically never exists during cryptographic processing — it is a claim about what the modernization workflow persists.
CAPA in practice
Modernizing historical encrypted data
An organization has millions of records or files encrypted over many years using cryptographic mechanisms that must now be replaced. The applications that originally produced the data may have changed, been retired, or no longer retain the original plaintext. The organization can transform the cryptographic protection of the existing data under new algorithms, keys or policies without requiring the originating applications to recreate it, and without creating persistent plaintext intermediate artifacts.
Correcting long-lived key dependencies
Large volumes of historical information may remain protected under the same keys or key structures for longer than the organization's current security policy permits. Frictionless modernization allows the organization to rotate, segment or migrate those protections to new keys and key hierarchies without reconstructing the systems that originally created the data. Modernization therefore addresses key-management debt as well as algorithmic obsolescence.
Migrating legacy cryptographic infrastructure
An organization needs to retire a legacy key store, trust infrastructure or cryptographic mechanism on which years of protected information still depend. Rather than performing a disruptive big-bang migration, the organization can progressively move cryptographic assets to the target infrastructure while business systems continue operating. The protection evolves independently from the lifecycle of the applications that originally created the data.
A practical test
Can the protection of data encrypted years ago be changed today, without the originating application and without plaintext at rest?
Pillar 04
Cryptographic Governance & Compliance
Cryptographic governance and compliance is the ability to translate internal security requirements, regulatory obligations, industry standards and jurisdictional constraints into centrally governed and enforceable cryptographic policies.
Organizations must be able to maintain multiple cryptographic policies simultaneously and apply them according to context — the data being protected, the operation being performed, the systems involved, the parties exchanging information, the purpose, the trust domain, and the jurisdictions or requirements that apply.
These policies govern permitted cryptographic mechanisms, security levels, key lifecycles, trust requirements and transition strategies through infrastructure rather than application-specific implementations. Governance must also provide visibility, traceability and evidence of policy enforcement — and must be able to evolve as regulations, standards, business relationships, jurisdictions and organizational structures change.
Core principle
Turn cryptographic requirements into enforceable policy and verifiable evidence.
What this pillar means
Requirements become policy
Security, regulatory, jurisdictional and organizational requirements are translated into enforceable cryptographic policy.
Policy follows context
Different policies apply according to data, operation, system, counterparty, purpose or jurisdiction.
Govern centrally, enforce consistently
Cryptographic decisions are managed through infrastructure rather than duplicated across applications.
Produce evidence
Visibility, traceability and enforcement records make cryptographic compliance demonstrable.
The conceptual chain
Requirements → Context → Policy → Enforcement → Visibility → Evidence → Evolution.
Governance is therefore not only policy definition. It includes enforcement, visibility, traceability, evidence, and the ability for policy itself to evolve.
CAPA in practice
Applying policy across multiple jurisdictions
A multinational organization operates across jurisdictions with different cryptographic requirements. Data processed within one jurisdiction may be governed by one policy, while information exchanged with headquarters, a regulated customer or an external provider may require another. The organization can maintain multiple cryptographic policies simultaneously and apply the appropriate one according to context — including data, operation, counterparty, purpose and jurisdiction.
Adapting governance after a merger or acquisition
An acquisition can change the cryptographic requirements applicable to systems and data even when no algorithm, standard or regulation has changed. New corporate policies, contractual obligations, jurisdictions or trust requirements may become applicable immediately. Centralized cryptographic governance allows the organization to introduce and enforce the resulting policies without requiring those decisions to be individually implemented within every affected application.
Enforcing a new enterprise security requirement
A security or compliance team determines that a particular algorithm, key lifecycle, security level or cryptographic strategy is no longer permitted for a category of information. The requirement is translated into centrally governed policy and enforced consistently across the affected systems. The same governance infrastructure provides visibility, traceability and evidence that the required policy was actually applied.
A practical test
Can the organization prove, by querying the control plane, which policy applied to a given operation, and change that policy centrally?
Pillar 05
Enterprise Readiness
Enterprise readiness is the ability of cryptographic infrastructure to operate as a native component of complex, heterogeneous enterprise technology environments rather than as another isolated security silo.
A modern cryptographic architecture must integrate or interoperate with the capabilities organizations already use: identity and access infrastructure, workload and machine identity, HSMs, KMS platforms, PKI and digital trust services, security operations, SIEM, XDR, logging, metrics, tracing, observability, monitoring and alerting, communications and notifications, operational tooling, and external cryptographic ecosystems.
It must also interoperate with external systems that may impose different protocols, formats, standards or cryptographic requirements. Enterprise readiness assumes that multiple technologies, providers and deployment models coexist, and must therefore support extensibility as those environments evolve.
Core principle
Cryptographic infrastructure must interoperate with the enterprise, not require the enterprise to adapt around it.
What this pillar means
Integrate with what exists
Works with existing identity, trust, key, security, observability, communications and operational systems.
Support heterogeneous environments
Multiple providers, technologies, trust domains and deployment models coexist.
Preserve existing investments
Governance improvement does not require immediate replacement or consolidation of enterprise infrastructure.
Interoperate externally
External protocols, cryptographic formats, representation profiles, standards and mechanism requirements can be supported without redefining the internal posture.
What this rules out
Existing investments should be preserved where appropriate rather than replaced merely to introduce centralized cryptographic governance. An architecture that requires the enterprise to consolidate its identity, key, trust, security or observability infrastructure before cryptographic governance can improve has not satisfied this pillar.
CAPA in practice
Integrating with the existing enterprise security ecosystem
An organization already operates enterprise identity and access infrastructure, workload identities, key management and hardware security systems, trust services, security monitoring, SIEM or XDR capabilities, observability platforms, communication services and operational tooling. A Cryptographic Control Plane integrates with these existing capabilities rather than creating parallel technology silos, allowing cryptographic operations to participate naturally in the organization's established security and operational ecosystem.
Operating across heterogeneous environments after an acquisition
Following an acquisition, two organizations may use different identity infrastructures, KMS and HSM environments, security monitoring platforms, observability tooling, trust services and deployment models. Establishing common cryptographic governance should not require immediate consolidation of those technologies. An enterprise-ready architecture can integrate with both environments while allowing each underlying technology or trust domain to be retained, evolved, migrated or consolidated independently according to security, resilience, jurisdictional and business requirements.
Interoperating with external cryptographic ecosystems
An organization may use one cryptographic posture internally while a customer, provider, government system, industry network or other external ecosystem requires different protocols, formats, standards or cryptographic mechanisms. Enterprise readiness enables the organization to participate in those ecosystems while preserving its internal architecture and cryptographic posture. External interoperability becomes an integration capability rather than a requirement to redesign the enterprise around each counterparty.
A practical test
Can the control plane be adopted without replacing the identity, KMS/HSM, PKI, or monitoring platforms already in place?