The Cryptographic Maturity Model

Audience: CISOs, CIOs, Enterprise Architects, transformation leads

Reading time: 18 minutes

Prerequisites: The Cryptographic Control Plane recommended

Purpose

Organizations differ significantly in how cryptography is implemented, governed, and evolved across their technology environments. Some still rely on cryptographic mechanisms embedded directly within application code, while others have introduced centralized key management, policy governance, and lifecycle management capabilities.

The Cryptographic Maturity Model is a diagnostic framework that:

1. Helps organizations understand their current position on the path toward governed cryptographic infrastructure
2. Defines what capabilities are required to advance from one level to the next
3. Provides a roadmap for cryptographic transformation that aligns with the post-quantum transition

Two principles underpin the model

Maturity is measured by capability, not by legacy migration progress. What matters is what the organization can do today in response to a vulnerability, a standard change, or an algorithm deprecation. A legacy estate in active migration does not reduce the maturity level — it represents work in progress, not a deficit of capability.

The ANKASecure Admin Console's Platform Overview posture band is consistent with this principle: although it displays operational figures such as migration progress, every pillar's green / amber / red status derives from capability (can the estate rotate, is custody configured, is policy declared), and the console issues no maturity verdict. It never converts migration progress into a maturity level.

Post-quantum cryptography is not a separate level. It is a dimension that improves at every level, and that can begin to be adopted from the moment the organization deploys a Cryptographic Control Plane. Rather than representing discrete technical deployments, the levels provide a diagnostic frame that helps organizations understand where they stand and what capabilities they need to develop next.

An organization operates at several levels at once, and that is the expected state. The model is not a gate sequence: a greenfield can sit at L5 while the brownfield sits at L2. Reading a single number for a whole enterprise usually hides the only useful question — which track is where, and what closes the gap.

The six levels

flowchart LR
    L1["L1<br/>Embedded<br/>cryptography"]
    L2["L2<br/>Managed<br/>cryptography"]
    L3["L3<br/>Cryptographic<br/>Control Plane"]
    L4["L4<br/>Cryptographic<br/>agility"]
    L5["L5<br/>Optimized<br/>cryptography"]
    L6["L6<br/>Continuous crypto<br/>evolution"]

    L1 --> L2 --> L3 --> L4 --> L5 --> L6

    style L1 fill:#fadbd8,stroke:#c0392b
    style L2 fill:#fdebd0,stroke:#d68910
    style L3 fill:#fcf3cf,stroke:#d4ac0d,stroke-width:3px
    style L4 fill:#d6eaf8,stroke:#2980b9
    style L5 fill:#d5f5e3,stroke:#1e8449,stroke-width:3px
    style L6 fill:#d1f2eb,stroke:#148f77

Level 3 is the structural inflection point. Level 5 is the strategic target; Level 6 is the long-term horizon, and it is a mode of operation rather than a milestone to be certified.

Level 1 — Embedded Cryptography

At this level, cryptographic logic is embedded directly within application code. Developers select algorithms, libraries, and parameters during implementation, and these decisions become tightly coupled with the application itself.

Common characteristics:

• Algorithm selection embedded in code
• Cryptographic libraries directly invoked by applications
• Inconsistent implementations across systems
• Limited visibility into where cryptography is used
• Manual upgrades when vulnerabilities emerge

Why this perpetuates itself. New applications are built with the same embedded patterns as legacy systems, because there is no architectural discipline or policy requiring otherwise. The cryptographic debt grows with every new deployment.

PQC at this level. Absent or isolated. If a team adopts a PQC algorithm, it is hardcoded into that application just as any classical algorithm would be — solving nothing at the structural level.

The transition out of Level 1 begins with a decision, not a project. The organization must commit to stopping the accumulation of new debt, even before resolving the existing debt. That commitment is the greenfield policy — and it can be established immediately at any subsequent level.

Level 2 — Managed Cryptography

At this level, organizations introduce centralized components that improve the management of cryptographic assets. This typically includes hardware security modules (HSMs), key management systems (KMS), certificate management platforms, and centralized key lifecycle management.

These technologies significantly improve the protection and governance of cryptographic keys. However, the structural problem remains: cryptographic logic is still embedded within application code.

The defining limitation: the KMS governs where keys are stored. It does not govern which algorithms are used, how cryptographic policies are enforced, or how algorithm transitions are orchestrated. Cryptographic upgrades still require modifications across multiple systems.

Level 2 is the earliest point at which the greenfield policy should be established. A formal commitment that all new applications developed from this point forward will not embed cryptographic logic directly, but will instead consume cryptographic services through an abstraction layer. This policy does not resolve existing technical debt — but it stops its accumulation.

PQC at this level. Can be introduced into the key management layer — PQC keys can be stored and rotated in the HSM or KMS — but algorithm governance remains per-application, making enterprise-wide PQC adoption uncoordinated and ungoverned.

Level 3 — Cryptographic Control Plane

Level 3 represents the structural inflection point of the maturity model. The organization deploys a Cryptographic Control Plane: a dedicated infrastructure layer that decouples cryptographic behavior from application code and centralizes its governance.

This is not an incremental improvement over Level 2. It is an architectural change that fundamentally alters the organization's capacity to govern, adapt, and respond.

The capability that defines Level 3 is not the existence of a cryptographic inventory — it is the ability to act on cryptographic policy without modifying or redeploying applications.

flowchart TB
    GREEN["🌱 New systems<br/>(greenfield)"]
    BROWN["🏗️ Legacy systems<br/>(brownfield)"]

    CCP["🏛️ Cryptographic<br/>Control Plane"]

    POL_GREEN["✅ Policy-governed<br/>from day one"]
    DISC["🔍 Discovery and<br/>phased migration"]

    GREEN --> CCP
    CCP --> POL_GREEN

    BROWN --> DISC
    DISC --> CCP

    style CCP fill:#fcf3cf,stroke:#d4ac0d,stroke-width:3px
    style GREEN fill:#d5f5e3,stroke:#1e8449
    style BROWN fill:#fdebd0,stroke:#d68910
    style POL_GREEN fill:#d5f5e3,stroke:#1e8449
    style DISC fill:#d6eaf8,stroke:#2980b9

From the moment the Control Plane is operational, all new systems are built without embedded cryptographic logic. They express cryptographic intent through a standardized service interface, and the Control Plane enforces the corresponding policy. Post-quantum algorithms become the default for all new applications immediately — not as an engineering project but as a policy decision.

For the existing legacy landscape, the Control Plane initiates a parallel process: discovery and phased migration. The brownfield estate is inventoried, systems are prioritized by PQC exposure and data sensitivity, and migration proceeds in structured phases.

The dual state at Level 3. Systems not yet migrated remain constrained by their embedded implementations — but they are no longer representative of the organization's current capability. The organization can already respond to a vulnerability in any governed system in hours. The legacy backlog is work in progress, not a measure of maturity.

Discovery is applied to the past. The Control Plane governs the future.

Level 4 — Cryptographic Agility

At Level 4, the Cryptographic Control Plane has been operational for a significant period and its coverage has expanded substantially across the enterprise landscape. The focus has shifted from deployment to depth of migration: the Control Plane now governs the most critical and most exposed systems, and the brownfield migration is in advanced stages.

Critical and high-risk systems — those with the greatest PQC exposure or the highest data sensitivity — have been migrated to the Control Plane and operate under centralized cryptographic governance. Algorithm transitions in these systems no longer require code changes; they are executed as policy updates that propagate in real time.

Hybrid coexistence of classical and post-quantum algorithms is managed centrally across the governed landscape. When a vulnerability is disclosed in an algorithm used by a critical system, the organization can respond in hours, not months.

The dual-track state

The defining characteristic of Level 4 is the dual-track state of the cryptographic environment.

flowchart LR
    subgraph GREENFIELD["🌱 Greenfield — fully governed"]
        G1["Every system since CCP adoption"]
        G2["PQC by default"]
        G3["Policy enforced centrally"]
        G4["Vulnerability response: hours"]
    end

    subgraph BROWNFIELD["🏗️ Brownfield — in advanced migration"]
        B1["Critical systems migrated"]
        B2["Lower-risk systems being onboarded"]
        B3["Vulnerability response varies"]
        B4["Gap closing systematically"]
    end

    style GREENFIELD fill:#d5f5e3,stroke:#1e8449
    style BROWNFIELD fill:#fdebd0,stroke:#d68910

The greenfield is fully governed: every system deployed since the adoption of the Control Plane operates under centralized policy, with PQC by default. The brownfield is in advanced migration: lower-risk and lower-priority systems are progressively being onboarded as planned maintenance windows allow.

The gap between these two tracks represents the remaining technical debt — and systematically closing it is the primary operational objective of Level 4. The organization's overall vulnerability response time reflects this dual state: hours for governed systems, days or weeks for those still in the migration queue.

Level 5 — Optimized Cryptography

Level 5 is the organizational equivalent of CMMI Level 5 — not a technology installed, but a mode of operation achieved.

At this stage, the cryptographic landscape is complete under the Control Plane. The brownfield migration is finished. No system in the organization has embedded cryptographic logic. Every cryptographic operation, across every system, is governed by centralized policy.

The defining capabilities

This is the level where cryptographic agility, posture visibility, and policy enforcement converge into a unified operational capability. The organization no longer manages cryptography as a series of engineering projects — it governs it as infrastructure policy.

When NIST publishes an update to a post-quantum standard, the organization adopts it in weeks, not years. When a vulnerability is disclosed, the response is measured in hours.

This is the strategic target that enterprises should aim to reach before regulatory PQC mandates arrive.

Level 6 — Continuous crypto evolution

Defining capability: cryptographic evolution is absorbed by established processes rather than run as a programme.

The distinction from Level 5 is not additional technology. At Level 5 the organization has the capability to absorb a change in algorithms, threats, standards, regulations, trust requirements or external ecosystems. At Level 6 that absorption is routine — it happens through the same governance and operational processes that handle patches, certificate renewals and capacity events, without a project being opened for it.

PQC at this level: classical, hybrid, post-quantum and future mechanisms coexist and evolve according to policy and context.

The greenfield and brownfield tracks

The maturity model is not a rigid progression in which organizations must complete one stage before entering the next. Many enterprises operate across multiple maturity levels simultaneously — some systems may still be at Level 1 while others have reached Level 3 or 4. This is not a failure of implementation; it is the expected reality of any enterprise transformation.

The model interprets this multi-level coexistence through the greenfield / brownfield distinction.

flowchart TB
    subgraph ORG["The organization at any point in time"]
        direction LR
        GREEN["🌱 Greenfield<br/><br/>All new systems and applications<br/>being developed today"]
        BROWN["🏗️ Brownfield<br/><br/>Existing landscape with<br/>embedded cryptographic logic"]
    end

    GREEN -->|"can adopt decoupled<br/>architecture immediately"| L5_FAST["May reach Level 5<br/>within months"]
    BROWN -->|"requires structured,<br/>phased migration"| L_GRADUAL["Progresses through<br/>Levels 2, 3, 4 over years"]

    style GREEN fill:#d5f5e3,stroke:#1e8449,stroke-width:2px
    style BROWN fill:#fdebd0,stroke:#d68910,stroke-width:2px
    style L5_FAST fill:#d5f5e3,stroke:#1e8449
    style L_GRADUAL fill:#fdebd0,stroke:#d68910

The greenfield represents all new systems and applications being developed today. These can — and should — adopt decoupled cryptographic architecture immediately, regardless of where the organization sits on the maturity model. The greenfield can reach Level 5 capability within months of initial deployment.

The brownfield represents the existing landscape of systems with embedded cryptographic logic. These require a structured, phased migration prioritized by risk and operational feasibility. The brownfield works through Levels 2, 3, and 4 over a period of years.

An organization may simultaneously operate a greenfield at Level 5 and a brownfield at Level 2. The maturity level of the overall organization reflects the weighted state of both tracks. The strategic objective is to progressively close the gap between them.

How a CAPA-enabled platform supports each level

The CAPA framework defines the operational capabilities required for organizations to move toward the highest level of cryptographic maturity. Platforms that operationalize CAPA — such as ANKASecure© — are not the destination that organizations reach when they arrive at Level 5. They are the instrument that organizations use to advance from wherever they currently stand.

The platform meets the organization where it is and enables progression at the pace the organization can sustain.

Quick self-assessment

Use this assessment to locate your organization. Be honest — overstating the level does not help.

flowchart TD
    Q1{"Can you change a cryptographic<br/>algorithm without redeploying<br/>application code?"}
    Q1 -->|"No"| Q1A{"Are keys centrally managed<br/>via HSM or KMS?"}
    Q1A -->|"No"| L1A["You are at Level 1<br/>Embedded Cryptography"]
    Q1A -->|"Yes"| L2A["You are at Level 2<br/>Managed Cryptography"]
    Q1 -->|"Yes, for some systems"| Q2{"Are critical and high-risk<br/>systems all governed by<br/>the Control Plane?"}
    Q2 -->|"No"| L3A["You are at Level 3<br/>Cryptographic Control Plane"]
    Q2 -->|"Yes"| Q3{"Is the entire landscape<br/>governed? No system has<br/>embedded cryptographic logic?"}
    Q3 -->|"No"| L4A["You are at Level 4<br/>Cryptographic Agility"]
    Q3 -->|"Yes"| Q4{"Are new standards, providers<br/>and jurisdictions absorbed by<br/>normal operations, without<br/>opening a programme?"}
    Q4 -->|"No"| L5A["You are at L5<br/>Optimized cryptography"]
    Q4 -->|"Yes"| L6A["You are at L6<br/>Continuous crypto evolution"]

    style L1A fill:#fadbd8,stroke:#c0392b
    style L2A fill:#fdebd0,stroke:#d68910
    style L3A fill:#fcf3cf,stroke:#d4ac0d,stroke-width:3px
    style L4A fill:#d6eaf8,stroke:#2980b9
    style L5A fill:#d5f5e3,stroke:#1e8449,stroke-width:3px
    style L6A fill:#d1f2eb,stroke:#148f77

Read the answer per track, not per organization: run the questions once for the greenfield and once for the brownfield. Two different answers is the normal result.

Validation questions

To confirm the level you reached:

What this means for the post-quantum transition

The emergence of post-quantum cryptography and increasing regulatory expectations will accelerate movement toward higher maturity levels. Organizations that develop the ability to govern cryptographic behavior through infrastructure will be significantly better positioned to adapt to future cryptographic transitions.

The question is not whether the post-quantum transition will require these capabilities. The question is whether organizations will arrive prepared, or under regulatory pressure with operational urgency.

The Cryptographic Maturity Model provides the diagnostic. The CAPA framework provides the capabilities. The deployment organization model provides the structural foundation. The Cryptographic Control Plane provides the architecture. Together, they make the transition manageable.

Where to read next

Summary

Maturity is measured by what the organization can do today, not by how much legacy migration remains pending. Post-quantum cryptography is a dimension that improves at every level. The greenfield can reach Level 5 within months while the brownfield works through earlier levels for years.

Six levels mark the path from embedded cryptography to continuous crypto evolution. L3 — the Cryptographic Control Plane — is the structural inflection point, the level at which policy can be acted on without modifying governed applications. L5 — Optimized cryptography — is the strategic target organizations should aim to reach before regulatory PQC mandates arrive, and L6 is the horizon beyond it: cryptographic evolution as normal practice rather than as a programme.