Next PCI DSS Version and the New PCI KMO Standard - 2 Key Takeaways from the 2026 PCI Community Meeting in Vancouver

Updated: 29 Sep 2026

What did the 2026 PCI Community Meeting in Vancouver mean for organisations in scope of PCI standards? Two announcements matter most in practice. First, PCI SSC published the PCI Key Management and Operations (KMO) Standard v1.0, which brings cryptographic key management across all PCI programmes into a single standard, starting with PIN and P2PE keys. Second, the next PCI DSS version is out for consultation, with publication estimated for Q2 2028 – a date the Council stresses is subject to change.

PCI Key Management and Operations (KMO) is a PCI SSC standard published on 14 September 2026 that sets security requirements and test procedures for entities managing cryptographic keys protecting PINs, account data and other sensitive assets throughout the key lifecycle.

Next PCI DSS version and PCI KMO – at a glance:

PCI SSC published PCI KMO v1.0 on 14 Sep 2026, the day before the North America Community Meeting opened (15-17 Sep 2026, Vancouver). It covers the full key lifecycle, from generation to destruction.
KMO is modular: common requirements apply to every entity, while service-specific requirements apply to six service types (DM, PPS, KIF, SSP, CA/RA, HaaS), mapped in Matrix 3 of the standard.
A single KMO assessment can validate both PIN keys and P2PE keys, following an “assess once, use many” model.
KMO may eventually take over from PCI PIN Security, but the payment brands decide which standard applies – until Visa and Mastercard publish bulletins, existing programmes stand.
The next PCI DSS version will go through two further Requests for Comments in 2027, with publication estimated for Q2 2028. This is not a fixed deadline.
Proposed direction: PCI 3DS Core and TSP requirements folded into PCI DSS as appendices, the customised approach and compensating controls merged into one mechanism, and clearer language on AI – without rewriting the whole standard as objective-based requirements.
PCI DSS v4.0.1 remains the only standard your QSA will assess against – waiting for the next version does not pause today’s obligations.
As an accredited QSA delivering PCI DSS, PCI PIN Security and PCI P2PE engagements, Patronusec helps organisations plan the move to KMO and the next PCI DSS version as one compliance roadmap rather than three parallel projects.

What did PCI SSC announce at the 2026 Community Meeting in Vancouver?

At the North America Community Meeting in Vancouver (15-17 Sep 2026), PCI SSC set out two directions with the greatest impact on the payments industry: the new PCI KMO v1.0 standard for cryptographic key management, and the roadmap for the next PCI DSS version, with publication estimated for Q2 2028. Both form part of a wider consolidation of PCI standards.

This year’s meeting was a milestone. PCI SSC marked its 20th anniversary, and according to the Council’s press release the event at the Vancouver Convention Centre brought together banks, retailers, payment service providers, assessors and technology vendors under a theme linking two decades of progress with the future of payment security. AI dominated the agenda – from pre-conference workshops on attack surfaces in agentic payment flows to the release of new Security Considerations for AI Systems guidance.

For organisations in scope of PCI programmes, the thread connecting the announcements matters more than any single one:

KMO replaces key-management requirements scattered across standards with one standard and service-specific modules,
the next PCI DSS version is expected to absorb PCI 3DS Core and Token Service Provider (TSP) requirements as dedicated appendices,
Secure Software Standard v2.0 had already created an alternative assessment route for 3DS SDKs under the same consolidation strategy.

The common denominator of the Vancouver announcements is modularity: PCI SSC is moving away from many standalone standards towards a shared core of requirements, supplemented by modules that apply only where an organisation actually performs the function concerned.

The same pattern is familiar from the PCI Software Security Framework, where additional modules apply only to specific software types. Over the next few years this should mean fewer parallel assessments, but it also puts the onus on organisations to establish precisely which modules apply to them.

What is the PCI Key Management and Operations (KMO) Standard?

PCI KMO v1.0 is a PCI SSC standard published on 14 Sep 2026 that defines security requirements, test procedures and guidance for entities operating systems that use cryptographic keys to protect account data. It covers the full key lifecycle, together with the procedures, systems and equipment used to manage and operate those keys.

According to the official PCI SSC announcement, the scope covers keys protecting PINs, account data and other sensitive assets – including keys used for storage, transport and derivation of other keys. The defining features of KMO v1.0 are:

Initial focus on PIN and P2PE keys. The standard consolidates, aligns and updates key-management requirements previously held separately in PCI PIN Security and PCI P2PE.
One assessment, two key types. A single KMO assessment can validate security for both PIN and P2PE keys, and the resulting KMO Listing can be referenced by a P2PE solution where appropriate.
Cloud and remote HSMs. KMO directly addresses HSMs consumed as a service and was developed in alignment with the recently published PCI HSM v5 requirements.
Room to grow. Future revisions may address other data types, such as those covered by the PCI Card Production standards.

The Requirements and Test Procedures v1.0 and the KMO Program Guide are already in the PCI SSC Document Library. The KMO Assessor Qualification Requirements are due shortly, so formal KMO assessments will only begin once the first assessors have qualified.

PCI KMO reverses the historic logic of PCI standards: rather than repeating key-management requirements in every standard, the Council now maintains them in one document that other programmes reference.

Example: a processor that translates PIN blocks for an acquirer and also runs the decryption environment for a P2PE solution currently presents evidence for the same HSMs, the same key ceremonies and the same key custodians in two separate assessments. Under KMO, the common requirements are assessed once, with the PPS and DM modules assessed on top.

Patronusec Insight: The trap we see most often in PIN and P2PE environments is documentation drift – the same key-generation ceremony described in two procedures, with different roles and different log formats. KMO will expose this immediately, because a single assessment demands one coherent picture of the key lifecycle. In our PCI PIN Security engagements we now restructure key-management procedures so they map cleanly onto KMO’s common requirements from day one.

Which organisations does PCI KMO apply to?

PCI KMO applies to entities that manage cryptographic keys protecting PINs or account data, whether for themselves or on behalf of others. The standard combines common requirements for every entity with service-specific requirements for six service types, and Matrix 3 of the standard sets out how they relate.

The six KMO service types:

KMO service type	What it covers	Typical entity
DM (Decryption Management)	Manages the decryption environment for a componentised P2PE solution	P2PE decryption component provider
PPS (PIN-Processing Service)	Performs PIN operations (e.g. verification, translation) without being the card issuer	Processor or acquirer agent translating PIN blocks
KIF (Key-Injection Facility)	Provides key services to other entities: generation, conveyance and local or remote key loading	POI terminal key-injection provider
SSP (Signing Service Provider)	Signs software or data packages (firmware, applications, configuration files) for other entities	Entity signing terminal firmware
CA/RA (Certification/Registration Authority)	Signs public keys (X.509 or other certificates) for remote distribution of symmetric keys; the RA vets certificate requests on the CA’s behalf	Certificate authority in a remote key loading scheme
HaaS (HSM-as-a-Service)	Manages an HSM cluster offered to other entities	Cloud or remote HSM provider

A single entity may perform several KMO service types at once – it then meets the common requirements once and the service-specific requirements for each service it provides.

Decision tree: does KMO apply to your organisation?

Do you generate, store, distribute, load or destroy keys protecting PINs or account data?
- No → KMO does not apply to you directly. Check whether your providers (processor, P2PE provider, HSM provider) will rely on it.
- Yes → go to question 2.
Do you provide DM, PPS, KIF, SSP, CA/RA or HaaS services, for yourself or for others?
- Yes → the KMO common requirements apply, plus the module for each service you provide (Matrix 3).
- Unsure → inventory your key operations and map them to service types before your next assessment.
Is your current validation driven by a payment brand PIN programme or a P2PE listing?
- Yes → maintain existing assessments until Visa and Mastercard publish bulletins, while preparing your KMO mapping in parallel.

Handling both PIN and P2PE keys, or providing KIF or HaaS services?

In a 30-minute call we will map your key operations to KMO service types and identify which elements of your current PCI PIN Security and P2PE assessments can be reused once you move to KMO.

Book a free consultation

Will PCI KMO replace the PCI PIN Security Standard?

Potentially, but not automatically. Vancouver signalled that KMO is intended to take over the key-management role of PCI PIN Security over time. However, the payment brands’ compliance programmes determine which standard an organisation must meet, so the forthcoming Visa and Mastercard bulletins will be decisive.

The distinction has real consequences. PCI SSC develops and maintains standards but does not enforce compliance – that falls to the payment brands (Visa, Mastercard) through their programmes, and to acquirers through their contracts. This applies especially to PIN security, where the obligation to be assessed, and how often, comes from each brand’s rules.

Publication of a standard by PCI SSC does not create a compliance obligation – the obligation arises only when a payment brand or acquirer writes that standard into its requirements.

Until the brands set out their positions, three working assumptions are sensible:

Current PCI PIN Security assessments remain valid and should continue on their existing schedule.
A transition period is likely. Visa and Mastercard may announce positions at different times with different dates, so both standards could run in parallel for a while.
P2PE solutions will be able to reference a KMO Listing, which should simplify validating the key-management components of PCI P2PE solutions over time.

The fix: do not postpone a scheduled PIN assessment while waiting for KMO, but use it to restructure your documentation so it fits the new standard.

When will the next PCI DSS version be published?

Based on the indicative roadmap shared in Vancouver, the next PCI DSS version is expected around Q2 2028. Before that, PCI SSC will run two further Requests for Comments in 2027, followed by stakeholder review and a Board of Advisors vote. The Council was explicit that all dates are subject to change.

Stage	Indicative timing	Status
RFC 1 on PCI DSS v4.0.1	2026	Completed; 884 comments from 70 organisations under review
RFC 2	Q1/Q2 2027	Planned
RFC 3	Second half of 2027	Planned
Further drafting, stakeholder review, Board of Advisors vote	After the RFCs	Planned
Publication of the next PCI DSS version	Estimated Q2 2028	Not fixed, subject to change

Q2 2028 is an estimate, not a compliance deadline – until the next version is published, PCI DSS v4.0.1 remains the only benchmark for a QSA assessment.

The market often calls the forthcoming release “PCI DSS v5.0”, but PCI SSC has not confirmed a version number. A transition period is also likely: PCI DSS v4.0 was published on 31 Mar 2022, while v3.2.1 was not retired until 31 Mar 2024. Even if the next version arrives on schedule, organisations should expect time to transition, although its length has not been announced.

What changes does PCI SSC plan for the next PCI DSS version?

PCI SSC set out four goals: extending the environmental security structure beyond one based solely on PAN, adding flexibility to scale security rigour to risk, establishing clearer scope and paths for users of PCI-validated solutions, and continuing to simplify validation options, standards and supporting documentation across the PCI ecosystem.

PCI 3DS Core and TSP as PCI DSS appendices

PCI SSC is considering bringing the PCI 3DS Core and Token Service Provider (TSP) requirements into PCI DSS, most likely as dedicated appendices. The key clarification from Vancouver: this does not make every merchant subject to 3DS or TSP requirements. They would apply only to organisations performing 3DS functions (such as an ACS, DS or 3DS Server) or issuing EMV payment tokens. For most entities assessed against PCI DSS today, the account-data requirements and validation approach would remain unchanged.

More objective-based requirements – but not an objective-based standard

The Council intends to simplify some of the most complex requirements and give organisations more latitude in how they meet security objectives. It was equally clear that it does not currently intend to rewrite the whole standard as objective-based requirements. The consultation feedback supports this: stakeholders are not asking for detail to be stripped out – if anything, they want more clarity and guidance.

Prescription is one of PCI DSS’s strengths – for organisations without large security teams, a precise description of what good looks like is worth more than a control objective alone.

Customised approach and compensating controls in one mechanism

The customised approach introduced in PCI DSS v4.0 lets an organisation meet a requirement’s objective through a different control design. Adoption has been lower than expected: organisations struggle to tell when to use the customised approach and when to use a compensating control, and the documentation can be substantial. The concept under discussion would merge both into a single mechanism for meeting a requirement differently, with one consolidated worksheet.

PCI-validated solutions

The fourth area is clearer scope and paths for organisations using PCI SSC validated solutions (such as P2PE or MPoC). For merchants, this is potentially the simplest route to reducing assessment scope.

How will the next PCI DSS version address artificial intelligence (AI)?

PCI DSS will remain technology-agnostic. If an AI system is a system component within, or can affect the security of, the PCI environment, the same requirements apply as for any other technology. The next version is expected to clarify language and guidance on AI systems, functionality and data flows, together with AI governance expectations.

The message from Vancouver was pragmatic: AI does not need a separate security universe within PCI DSS. Rather than bolting on dozens of AI-specific technical controls, the Council is considering governance expectations built around five questions:

Where are we using AI?
What is it being used for?
What data can it access?
Who is permitted to use it?
What does acceptable use look like?

Alongside this, PCI SSC released its Security Considerations for AI Systems guidance during the Community Meeting, expanding on the AI principles it issued in 2025.

AI in a payment environment is a governance and scoping question rather than a separate technical category – an AI system with access to account data falls under PCI DSS on the same terms as any other system component.

Organisations already using AI for customer service, fraud analytics or IT operations near the CDE should start with a register of use cases and an acceptable use policy. For the payments-specific risk picture, see our analysis of agentic payments security by role.

What did the industry raise in the first RFC on PCI DSS v4.0.1?

In the first Request for Comments on PCI DSS v4.0.1, 70 organisations submitted 884 comments. Requirements 6, 11 and 12 drew the most feedback, particularly payment-page script controls under requirements 6.4.3 and 11.6.1. Recurring themes also included AI, cloud, APIs, MFA, passkeys, passwords and cryptography.

The recurring themes raised by respondents:

AI, cloud and APIs,
authentication, MFA and passkeys,
password requirements and alignment with current industry practice,
cryptography, key management and keyed hashing,
remote-access controls,
requirements 6.4.3 and 11.6.1 for payment pages.

Requirements 6.4.3 and 11.6.1 remain the most debated area of PCI DSS v4.0.1 – in PCI SSC’s consultation and in day-to-day assessment practice alike.

Note the overlap with the first takeaway: cryptography and key management feature both in the PCI DSS feedback and in the new KMO standard. It is reasonable to expect PCI SSC to push for consistent cryptographic requirements across both documents.

What should your organisation do now?

Don’t wait. PCI DSS v4.0.1 is the standard in force, and well-implemented controls will not lose their value when a new version appears. Today’s priorities are payment-page security, vulnerability management, authentication, third-party management, reducing PCI scope and building an inventory of AI use in and around the payment environment.

Recommended actions by organisation profile:

Merchants and service providers in scope of PCI DSS:

complete implementation of v4.0.1, particularly 6.4.3 and 11.6.1, multi-factor authentication and third-party management,
reduce PCI scope wherever you legitimately can, and evaluate validated solutions (P2PE, tokenisation),
inventory AI use cases in and around the CDE.

Entities managing keys (PIN, P2PE, KIF, HSM):

map your key operations to KMO service types,
check that key ceremony procedures are consistent across your PIN and P2PE assessments,
confirm whether your cloud HSM provider plans to align with PCI HSM v5,
monitor Visa and Mastercard bulletins on the status of KMO.

Good security architecture implemented today will not become bad practice simply because a new version number appears.

Patronusec Insight: In our project experience, organisations that defer requirements 6.4.3 and 11.6.1 “until the next version” arrive at assessment with a finding in precisely the area the Council identified as most commented on – not as earmarked for removal. Consultation may change how these requirements are worded, but not what they are there to achieve. A PCI DSS v4.0.1 gap analysis shows what must be closed now and what is worth designing flexibly with the next version in mind.

Which misconceptions about PCI KMO and the next PCI DSS version should you avoid?

Several oversimplifications have circulated since the Community Meeting, and they can lead to poor budgeting and project decisions. The pairs below set them against what PCI SSC actually announced.

MYTH: PCI KMO has already replaced PCI PIN Security.
FACT: KMO v1.0 was published on 14 Sep 2026, but payment brand programmes determine which standard is required. Until Visa and Mastercard issue bulletins, existing requirements apply.

MYTH: The next PCI DSS version becomes mandatory in 2028.
FACT: Q2 2028 is an estimated publication date that the Council describes as subject to change. No effective date or transition period has been announced.

MYTH: Once 3DS Core moves into PCI DSS, every merchant must meet 3DS requirements.
FACT: 3DS and TSP requirements are intended to apply only to organisations performing those functions.

MYTH: The next PCI DSS will be entirely objective-based.
FACT: PCI SSC does not currently intend to rewrite the whole standard as objective-based requirements; prescription stays where it adds value.

MYTH: AI will need its own set of PCI DSS controls.
FACT: PCI DSS remains technology-agnostic; expected changes concern clearer language, guidance and AI governance expectations.

FAQ

When and where was the 2026 PCI Community Meeting held?

The North America Community Meeting took place on 15-17 Sep 2026 at the Vancouver Convention Centre, Canada. It marked PCI SSC’s 20th anniversary. The Council is also holding 2026 Community Meetings in Edinburgh and Kuala Lumpur.

Is PCI KMO mandatory yet?

Not automatically. The standard was published on 14 Sep 2026, but a compliance obligation arises only when a payment brand or acquirer adopts it into its requirements. The KMO Assessor Qualification Requirements have not yet been published, so formal KMO assessments are still to begin.

How does PCI KMO differ from PCI PIN Security?

PCI PIN Security covers PIN security as a whole, including PIN key management. PCI KMO focuses on key management and cryptographic operations across several data types at once – PIN and P2PE in version 1.0 – using a modular structure of common and service-specific requirements for six service types.

Do merchants need to comply with PCI KMO?

Usually not. KMO applies to entities managing cryptographic keys, such as PIN processors, P2PE decryption providers, key-injection facilities and HSM providers. A merchant using a P2PE solution will feel the change indirectly, through how its provider is validated.

When will PCI DSS v5.0 take effect?

That is not yet known, and PCI SSC has not confirmed the version number. Publication of the next version is estimated for Q2 2028, subject to change. A transition period is likely: when v4.0 was published in March 2022, v3.2.1 was retired in March 2024.

Will the changes affect organisations using the customised approach?

Probably, and for the better. PCI SSC is considering merging the customised approach and compensating controls into one mechanism with a single worksheet. Until a new version is published, the current rules and templates in PCI DSS v4.0.1 apply.

How can Patronusec help you prepare for KMO and the next PCI DSS version?

As a QSA delivering PCI DSS, PCI PIN Security and PCI P2PE engagements, we review key management and PCI DSS compliance within one project. Following a free scoping call, we provide a fixed-price quote for a gap analysis or KMO mapping, with a guaranteed report delivery date.

Blog space

Next PCI DSS Version and the New PCI KMO Standard – 2 Key Takeaways from the 2026 PCI Community Meeting in Vancouver

In this article you will learn:

Table of Contents