If your PCI program still treats “future-dated requirements” as a phrase you can put off, you’re already behind. Those requirements, once considered best practices under PCI DSS 4.0, became mandatory on March 31, 2025, and organizations are now expected to validate against the full standard. For ISVs, that shift matters more than it might seem, because it’s not just merchants who get graded on this standard anymore. Any software you build or maintain that stores, processes, or transmits cardholder data, even indirectly through a hosted payment page or an embedded iframe, falls under scope.
The version number causes some confusion, so it’s worth clearing up. PCI DSS v4.0.1 replaced v4.0 with clarifications and editorial improvements, not new technical requirements, and it didn’t change or delay the March 2025 deadline for future-dated requirements. If you’re hearing about a 2026 deadline from a vendor or consultant, that’s not a new compliance date. It generally refers to the first assessment cycle, SAQ filing, ROC, or acquirer remediation window where the 2025 requirements become fully effective in practice. In other words, 2026 is the year assessors stop giving credit for good intentions.
What your assessor actually expects now
The headline change in 4.0 was authentication. Password requirements now call for 12 characters at minimum, with an 8-character floor only permitted for legacy systems that can’t yet support the higher bar, and any exception needs to be documented with a remediation plan. If your platform still ships with 8-character defaults and no upgrade path, that’s a conversation to have with your engineering team before your next assessment, not during it.
Multi-factor and phishing-resistant authentication get more scrutiny too. According to PCI SSC guidance referenced in recent industry coverage, simply enabling phishing-resistant authentication doesn’t automatically satisfy every related requirement, though FIDO2 passkeys are recognized as meeting the specific control governing authentication factor strength. If your product handles admin access to cardholder data environments, it’s worth confirming your authentication stack actually maps to the requirement your assessor will cite, not just the spirit of it.
Third-party relationships also got a rewrite. The requirement covering third-party service provider relationships now includes clearer guidance on which party, you or your customer, is responsible for which piece of compliance when a hosted payment page or embedded iframe is involved. That ambiguity used to be a gray area ISVs could lean on. It isn’t anymore, and your contracts and documentation should reflect it.
Where ISVs tend to get tripped up
The most common gap isn’t a missing control. It’s assuming a previous assessment still counts. If your last validation was under 3.2.1, or under 4.0 without the future-dated requirements fully implemented, your next assessment will fail unless those gaps get closed first. That’s a resourcing and timeline problem as much as a technical one, so it deserves a spot on your roadmap now rather than a scramble two weeks before your assessor calls.
Scope reduction is the other lever worth pulling. Tokenization and point-to-point encryption won’t eliminate your PCI obligations, but they can meaningfully shrink what’s in scope, which shrinks both your audit burden and your risk exposure. If your architecture still routes raw card data through systems you control when it doesn’t need to, that’s the highest-leverage fix available to most ISVs right now.
One more thing worth flagging to your team: PCI SSC has been explicit that the only documentation it recognizes for validation is its own official form, and that any compliance certificate a vendor hands you isn’t authorized or validated by the council. If a payment partner or subprocessor is waving a glossy certificate instead of an Attestation of Compliance, that’s worth a second look before you rely on it.
What’s next for the standard
PCI DSS 4.0.1 isn’t the end of the story. The council closed a request for comments running from June 3 to July 20, 2026, asking the industry where the standard should head to account for future technology and AI innovation, and a separate second RFC cycle for PCI DSS v5.0 wrapped in December 2025 with no release date announced yet. History suggests you have runway here. PCI DSS 4.0 was published in 2022 and its predecessor stayed active for two more years before retiring, so v4.0.1 is likely to govern at least your next two annual assessment cycles. That’s not a reason to relax. It’s a reason to get your current house in order before a new set of requirements lands on top of the ones you’re still catching up on.
For most ISVs, the practical next step isn’t a philosophical debate about where PCI is headed. It’s a straightforward gap analysis against the version of the standard you’re actually being assessed on today. A structured compliance checklist, walked through with your security and engineering leads, is usually the fastest way to find out where you stand before your assessor does.
