TL;DR: PKI Maturity Model 2.0.0 is in public preview, and its headline change is a new Cryptography category in the Governance module. Cryptographic decisions that were scattered through certificate and key management now have one coherent home.
Asking a certificate management process to govern cipher suites was always a category error. 2.0.0 fixes the taxonomy rather than adding to it.
The PKI Maturity Model is developed by a working group at the PKI Consortium. Version 1.0.0 formalised five maturity levels across four modules and fifteen categories. Since then, assessors have used it on real programmes, and the friction they reported has shaped this revision.
Version 2.0.0 is now available as a public preview. This post walks through what changed and what it means if you have already completed an assessment.
The new Cryptography category
Governance gains one category: Cryptography. It centralises governance of cryptographic algorithms and parameters, protocols and versions, cryptographic asset visibility, and cryptographic lifecycle, deprecation, and agility.
Previously those concerns sat inside Key management and Certificate management as cipher-suite requirements. That placement caused overlap and ambiguous terminology. Consequently two assessors could reasonably disagree about where a finding belonged.
The new category carries six requirements.
| Requirement | What an assessor evaluates |
|---|---|
| Terminology and scope | Whether cryptographic terminology and scope applicable to the PKI are defined and documented |
| Algorithms and parameters | Whether algorithms and parameters in use are documented and formally approved |
| Protocols and versions | Whether protocols and protocol versions in use are documented and approved |
| Visibility of usage | Whether visibility into actual cryptographic usage is established and maintained |
| Lifecycle and deprecation | Whether cryptographic lifecycle and deprecation rules are defined |
| Cryptographic agility | Whether agility is defined and governed — the ability to replace algorithms or parameters in a controlled way |
Read that list next to any post-quantum migration plan. Four of the six are prerequisites for one, and most organisations discover they cannot evidence them.
Two requirements were removed
Consolidation cuts both ways. Certificate management loses “Certificate cipher suites are documented”, and Key management loses “Cryptographic cipher suites and protocols are documented and maintained”.
The reasoning is worth stating plainly. Cipher suites are a protocol-level concept, associated mainly with TLS and similar protocols. Certificates do not define or negotiate them. Therefore keeping that requirement in Certificate management mixed cryptographic governance with certificate lifecycle management.
Key management had the same problem from the other direction. Algorithm and protocol approval are governance concerns, not key lifecycle concerns. So Key management now focuses purely on the key lifecycle, and Certificate management on the certificate lifecycle.
Changes that affect your existing reports
Several changes are structural rather than substantive. Still, they touch anything you have automated or bookmarked.
Maturity level 2 is renamed from “Basic” to “Foundational”. The level number and the description of what achieving it means are unchanged, so the rename is about conveying intent. Existing 1.0.0 reports remain valid. However, if you reissue one, update the label.
Stable identifiers replace position-based numbers. Categories and requirements were previously referenced as G.1 and G.1.1; they are now G.strategy-and-vision and G.strategy-and-vision.sponsor-support. Because the identifiers are stable, they survive future minor releases. Anything you built against the numbers will need updating once.
Category page URLs also dropped their numeric prefixes, so bookmarks pointing at 01-… style paths should move to the identifier-only form. Additionally, a shared references catalog now holds the standards, regulations, and publications the model cites, which means titles and links can be maintained centrally between major releases.
Tools moved, and one was retired
The Excel-based assessment tools are retired as of 2.0.0, superseded by the web self-assessment. They remain reachable at the 1.0.0-tagged URLs and in the 1.0.0 website section. But if you automated against a main-pinned path, that link will stop resolving.
The Eramba CSV converter scripts moved to a separate integrations repository. Similarly, published extensions now live in their own catalog rather than shipping with the core model.
If you assessed against 1.0.0
The practical impact is smaller than a major version bump suggests.
Categories carried over from 1.0.0 have no content changes beyond the two cipher-suite removals. Therefore scores may need a small re-evaluation where that removed requirement materially influenced a level. For most assessments the effect is minor and limited to a single requirement.
The real work is additive. Organisations that completed a 1.0.0 assessment should add the Cryptography category to their next cycle. That is the one place where 2.0.0 asks genuinely new questions.
Why this matters beyond the model
OmniTrust participates in the PKI Maturity Model working group, and we think this revision is the right kind of change. It does not chase new topics. Instead, it repairs a taxonomy that had cryptographic governance filed under lifecycle management.
That repair matters because the industry is being asked, all at once, to inventory its cryptography, shorten certificate lifetimes, and plan a post-quantum migration. None of those is achievable without knowing which algorithms you use and who approved them. A maturity model that scatters those questions across three categories cannot measure whether you know.
The model is developed in the open, and the working group welcomes input. If you assess PKI programmes for a living, the preview is the moment your objections are cheapest to act on.
Key Takeaways
- Governance gains a Cryptography category with six requirements, covering algorithms, protocols, usage visibility, lifecycle, deprecation, and agility.
- Two cipher-suite requirements were removed, from Certificate management and Key management respectively.
- Maturity level 2 is renamed Basic to Foundational; the level and its meaning are unchanged.
- Stable string identifiers replace position-based numbers, and category URLs dropped numeric prefixes.
- Excel assessment tools are retired in favour of the web self-assessment; 1.0.0-tagged copies remain available.
New to the model? Start with the PKI Maturity Model from ad-hoc to governed operations. The new Cryptography category is easier to evidence once you have an inventory, so building a cryptographic asset inventory is a sensible companion. For the platform side, see 10 things you can build with ILM, or talk to us about an assessment.
