PKI Maturity Model 2.0.0 — Summary of changes
Under development This version has not yet been released. Content and timing are subject to change.
This document summarises the changes from PKI Maturity Model 1.0.0 to 2.0.0. It is intended for assessors, consultants, and PKI program owners who use the model to evaluate or improve PKI programs.
Change types
This summary uses the following change-type vocabulary:
| Change type | Definition |
|---|---|
| Evolving | Changes ensuring the model is up to date with emerging threats and technologies. Examples include new or removed categories or requirements. |
| Clarification or Guidance | Updates to wording, explanation, definition, or label to increase understanding without changing the intent of an existing assessment. |
| Structure or format | Reorganisation of content — including category and requirement renaming, identifier changes, or reorganisation — to align content. |
Summary of general changes
- Maturity level 2 was renamed from “Basic” to “Foundational” to better convey the level’s intent. The level number and the description of what it means to achieve that level are unchanged. Clarification or Guidance
- Stable identifiers were introduced for categories and requirements. Previously, categories and requirements were referenced by position-based numbers (e.g.,
G.1,G.1.1); they are now referenced by stable string identifiers (e.g.,G.strategy-and-vision,G.strategy-and-vision.sponsor-support). These identifiers remain valid across future minor releases. Structure or format - A shared references catalog was introduced for the standards, regulations, and publications cited from the model. Reference titles and links can now be maintained centrally between major releases. Structure or format
- Category page URLs and headings no longer carry numeric position prefixes — bookmarks or report links should be updated. Structure or format
Summary of changes to modules
| Module | Change | Change type |
|---|---|---|
| Governance | Added the Cryptography category (see Categories below). | Evolving |
(Management, Operations, and Resources have no module-level changes in 2.0.0.)
Summary of changes to categories
| Category | Change | Change type |
|---|---|---|
| Cryptography (Governance, new) | New category that centralises governance of cryptographic algorithms and parameters, protocols and versions, cryptographic asset visibility, and cryptographic lifecycle, deprecation, and agility. Previously these concerns were spread across Key management and Certificate management as cipher-suite requirements, leading to overlap and ambiguous terminology. The new category consolidates them into a single coherent place. | Evolving |
| Certificate management (Management) | Removed the “Certificate cipher suites are documented” requirement. Cipher suites are a protocol-level concept primarily associated with TLS and similar protocols; certificates themselves do not define or negotiate them. Including this requirement in Certificate management mixed cryptographic governance with certificate lifecycle management. Cryptographic algorithm and protocol governance is now handled centrally in the new Cryptography category, so Certificate management focuses on certificate lifecycle topics. | Evolving |
| Key management (Management) | Removed the “Cryptographic cipher suites and protocols are documented and maintained” requirement. Algorithm and protocol approval are governance concerns, not key lifecycle concerns. The requirement duplicated cryptographic decision-making that is now covered in the new Cryptography category, so Key management focuses exclusively on key lifecycle topics. | Evolving |
(Other categories carried over from 1.0.0 have no content changes in 2.0.0. The category-page format updates noted under “General changes” apply uniformly.)
Summary of changes to requirements
| Category | Requirement | Change | Change type |
|---|---|---|---|
| Cryptography | Cryptographic terminology and scope are defined and documented | Added. Assessors evaluate whether the organisation has defined and documented the cryptographic terminology and scope applicable to its PKI. | Evolving |
| Cryptography | Cryptographic algorithms and parameters are documented and approved | Added. Assessors evaluate whether the organisation has documented and formally approved the cryptographic algorithms and parameters in use across its PKI. | Evolving |
| Cryptography | Cryptographic protocols and versions are documented and approved | Added. Assessors evaluate whether the organisation has documented and approved the cryptographic protocols and protocol versions in use. | Evolving |
| Cryptography | Visibility into cryptographic usage is established and maintained | Added. Assessors evaluate whether the organisation has established and maintains visibility into its actual cryptographic usage. | Evolving |
| Cryptography | Cryptographic lifecycle and deprecation rules are defined | Added. Assessors evaluate whether the organisation has defined cryptographic lifecycle and deprecation rules. | Evolving |
| Cryptography | Cryptographic agility is defined and governed | Added. Assessors evaluate whether the organisation has defined and governs cryptographic agility — the ability to replace cryptographic algorithms or parameters in a controlled way in response to threats or regulatory requirements. | Evolving |
| Certificate management | Certificate cipher suites are documented | Removed. Cipher suites are a protocol-level concept; their governance is now handled in the new Cryptography category. | Evolving |
| Key management | Cryptographic cipher suites and protocols are documented and maintained | Removed. Algorithm and protocol approval are governance concerns; they are now covered in the new Cryptography category. | Evolving |
Summary of changes to extensions
2.0.0 is the first release of the PKI Maturity Model that supports extensions. An extension is an optional overlay that adds emphasis, additional requirements, or alternative weighting for a specific risk profile or industry context. Extensions do not change the core model; they supplement it for organisations that need a more targeted view.
PQC Readiness Extension
The PQC Readiness Extension is the first published extension. It overlays the Governance module categories with post-quantum cryptography readiness criteria, maturity guidance, and requirement-weight adjustments. When enabled during an assessment, it evaluates how prepared an organisation is to migrate its PKI to quantum-safe cryptography. The extension is opt-in; it has no effect on organisations that do not enable it.
The extension is currently under development. The Governance criteria are complete; criteria for the Management, Operations, and Resources modules are still being developed and will land in a subsequent release.
Notes for assessors and consultants
- Category URL changes. Bookmarks pointing to old
01-…,02-…style category URLs should be updated to the new identifier-only form (for example,categories/strategy-and-vision/). - Reports referencing “level 2 — Basic”. Existing assessment reports completed under 1.0.0 are not invalidated. If you regenerate or reissue a report, update references from “level 2 — Basic” to “level 2 — Foundational” to align with 2.0.0 terminology.
- Existing assessments. Categories carried over from 1.0.0 have no content changes other than the cipher-suite removals from Certificate management and Key management. Scores for those categories may need a small re-evaluation if the removed requirement materially influenced the maturity level; for most assessments the impact is minor and limited to a single requirement.
- Cryptography category. Organisations that completed a 1.0.0 assessment should add the Cryptography category to their next assessment cycle.
- PQC Readiness Extension. Organisations not concerned with post-quantum migration are unaffected. The extension applies only when explicitly enabled.
- Questions and discussions. Engage with the working group via the PKI Maturity Model community discussion.
