The framework convergence: why MFA, encryption, and audit trails became table stakes

Three controls have become table stakes in regulated software procurement, and they have become so on a calendar that is unusually compressed. Multi-factor authentication on every login. Encryption of data at rest and in transit by default. Audit trails whose integrity is cryptographically demonstrable. Five years ago, each of the three was a feature you would put in an enterprise-tier pricing sheet. Today, each of the three appears as a mandatory requirement in every major framework a regulated organisation has to comply with, and the cadence at which they all moved is striking enough to be worth naming.

The eighteen-month window from October 2024 to July 2025 is when the convergence completed. NIS2's Commission Implementing Regulation (EU) 2024/2690 landed on 17 October 2024, translating Article 21 into 150-plus auditable controls. The Microsoft Azure portal began enforcing MFA on 15 October 2024. The HIPAA Security Rule NPRM was published on 27 December 2024, removing the "addressable" versus "required" distinction across the board. The PCI DSS 4.0.1 future-dated controls, including universal MFA into the cardholder data environment, became mandatory on 31 March 2025. The ISO 27001:2013 transition window closed on 31 October 2025, leaving only ISO 27001:2022 with its explicit MFA and tightened cryptography expectations. NIST SP 800-63B-4 was finalised in July 2025, hardening phishing-resistant MFA at Authenticator Assurance Levels 2 and 3. AWS extended root MFA enforcement to organisation member accounts on 17 June 2025. The ADHICS V2 Q4 2025 compliance deadline. The FINMA Guidance 05/2025 effective on 1 January 2026.

The same three controls. Eighteen months. Nine frameworks across six jurisdictions. The procurement question has shifted from "do you have these" to "do you have them designed in or bolted on", because every regulated buyer is being asked to evidence them, and the buyer's vendor either makes that easy or makes it impossible.

The shift: three controls, eighteen months, every major framework

The convergence is not a narrative device. It is a calendar event with named effective dates. Each of the three controls has its own trajectory through the framework literature, and each ended up at the same place at roughly the same time.

MFA moved from a 2017 NIST recommendation about deprecating SMS as an out-of-band factor, through the 2018 PCI DSS 3.2.1 requirement covering only administrative access to the cardholder data environment, into the 2022 OMB M-22-09 mandate for phishing-resistant MFA across US federal civilian agencies, into the 2022 ISO 27001 revision that made MFA explicit in Annex A.8.5, and finally into the PCI DSS 4.0.1 universal-MFA effective date of 31 March 2025 and the NIST SP 800-63B-4 final publication in July 2025 that effectively retired phishable factors at AAL2 and above. The cloud providers enforced it in parallel: Microsoft Azure portal MFA mandatory from 15 October 2024, AWS root MFA on management accounts in May 2024 and member accounts in June 2025, Google Workspace 2SV enforcement rolled across editions in 2024.

Encryption followed a slower arc but arrived at the same point. GDPR Article 32(1)(a) has named "the pseudonymisation and encryption of personal data" as an example of an appropriate measure since 2018. EDPB and national supervisory authorities have hardened that example into an enforcement baseline through 2023 and 2024 fines, including the EUR 79 million Italian Garante penalty against ENEL Energia citing Articles 5(1)(f) and 32. The PCI DSS 4.0.1 stored-data and transmission encryption requirements (Requirements 3 and 4, AES-128 minimum with AES-256 typical, TLS 1.2 or higher) became fully enforced on 31 March 2025. NIST published the first post-quantum cryptography standards (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) on 13 August 2024, and the CNSA 2.0 timeline now mandates quantum-resistant algorithms in new US national security systems by 1 January 2027. The HIPAA NPRM made ePHI encryption at rest and in transit mandatory, removing the addressable carve-out. Cloud-provider defaults followed: S3 has encrypted new objects by default since January 2023, Google Cloud Storage default-encrypts with the option of customer-managed keys on every service.

Audit trail integrity moved last and fastest. The 2022 ISO 27001 revision merged the three 2013 logging controls (A.12.4.1 through A.12.4.3) into a single A.8.15 with explicit log-tampering protection. PCI DSS 4.0.1 Requirement 10.3.2 ("audit log files are protected to prevent modifications by individuals") and 10.3.4 (file integrity monitoring with alerting on modification) became mandatory on 31 March 2025. The NIS2 Implementing Regulation 2024/2690 annex and ENISA's Technical Implementation Guidance both call for cryptographic protection of logs where appropriate. NIST SP 800-53 AU-9(3) cryptographic protection of audit information has been on the books for years; the difference in 2025 is that FedRAMP 3PAOs now flag it routinely. The companion articles on continuous evidence and tamper-proof audit trails cover the audit-log integrity shift in detail.

The pattern across all three: every major framework arrived at the same operational requirement within eighteen months, with overlapping effective dates clustered between October 2024 and the end of 2025. The shift is not coming. It happened.

MFA: from admin-only to everywhere, and now phishing-resistant

Most platforms that offer MFA in 2026 still offer the version regulators have started writing out of the frameworks. Time-based one-time passwords delivered to an authenticator app. SMS codes. Push notifications without number-matching. Each is bypassable at scale: the Verizon Data Breach Investigations Report 2025 explicitly calls out push, OTP, and number-match MFA as "bypassed at scale" and points to phishing-resistant alternatives. The DBIR found compromised credentials were the initial access vector in 22% of analysed breaches and that 88% of attacks against basic web applications involved stolen credentials. Approximately 2.8 billion passwords were posted on criminal markets in 2024 alone.

The framework response converged on phishing-resistant MFA: hardware-bound credentials using FIDO2 and WebAuthn, or PIV smart cards in federal contexts, with explicit user intent and non-exportable private keys. CISA's October 2022 factsheet was direct: "the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication". OMB M-22-09 mandated phishing-resistant MFA across US federal civilian agencies. NIST SP 800-63B-4, finalised in July 2025, requires AAL2 to offer a phishing-resistant option and AAL3 to use a phishing-resistant authenticator with a non-exportable private key.

The cross-framework picture in 2026, walking through international and Western frameworks before MENA: GDPR Article 32 hardened by EDPB practice into a baseline MFA expectation for systems processing personal data, especially remote and administrative access. NIS2 Article 21(2)(j) explicitly names "the use of multi-factor authentication or continuous authentication solutions" as a minimum measure, with the Implementing Regulation 2024/2690 detailing the technical controls. ISO 27001:2022 A.8.5 Secure Authentication tells implementers to use MFA and not to reveal which factor failed during a failed login. SOC 2 CC6.1 explicitly calls out MFA for privileged and remote access in the 2022 revised points of focus. PCI DSS 4.0.1 Requirement 8.4.2 mandates MFA for all access into the CDE (not just administrative) and Requirement 8.5 sets system-configuration requirements with no bypass when the second factor fails. NIST SP 800-53 IA-2(1) covers privileged accounts and IA-2(2) non-privileged accounts. HIPAA's December 2024 NPRM moves MFA from addressable to required, with explicit safeguard requirements for any action that changes user privileges or PHI access. FINMA Circular 2023/1 expects MFA for privileged and remote access in line with the broader operational-resilience posture. ADHICS V2 mandates MFA for all PHI access, not just administrative. SAMA's Cyber Security Framework Domain 3.3.5 requires granular MFA and access policies per user, group, organisational unit, with policies varying by session type, device, location, and time.

The Change Healthcare breach in February 2024 is the single most instructive cost-of-absence example for the era. BlackCat ransomware used stolen Citrix credentials on a portal with no MFA, ultimately affecting approximately 190 million Americans, the largest healthcare breach in US history. UnitedHealth Group's own head of cybersecurity was aware MFA was missing on that portal despite company policy. Direct attack cost to UnitedHealth was reported at approximately $872 million, with economic damage across the US healthcare payment system exceeding that. The Snowflake-customer compromises through 2024 (Ticketmaster, AT&T, Santander, Advance Auto Parts, among approximately 165 affected environments) tracked the same pattern: absent or weak MFA on tenant accounts, attackers entering via stolen credentials. Snowflake subsequently moved toward enforcing MFA by default for new accounts. Microsoft has long cited internal data that MFA blocks over 99.2% of account compromise attacks; the breaches that did happen overwhelmingly hit the small fraction without it.

Encryption: from addressable to required

Encryption is the control where "addressable" carve-outs survived longest and have now been removed almost everywhere. The HIPAA Security Rule made encryption of ePHI "addressable" in 2003, which many covered entities interpreted as "optional if documented", and the practice persisted for two decades. The December 2024 NPRM eliminates that interpretation: encryption at rest and in transit becomes required for all ePHI, with limited exceptions.

The framework picture across encryption in 2026: GDPR Article 32(1)(a) names "the pseudonymisation and encryption of personal data" as an appropriate technical measure, with EDPB Guidelines 01/2025 on Pseudonymisation (adopted January 2025) providing the first detailed technical interpretation of what pseudonymisation actually requires (separation of additional information, cryptographic controls, key management). NIS2 Article 21(2)(h) requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption", with the Implementing Regulation 2024/2690 detailing what that means in practice. ISO 27001:2022 A.8.24 Use of Cryptography consolidates the 2013 controls and is explicit on key management lifecycle. SOC 2 CC6.7 requires encryption during transmission, movement, and removal of confidential information. PCI DSS 4.0.1 Requirement 3 mandates stored account data encryption (PAN unreadable, AES-128 minimum, AES-256 typical), Requirement 4 requires TLS 1.2 or higher for transmission with TLS 1.0/1.1 prohibited. NIST SP 800-53 SC-8 covers transmission confidentiality and integrity and SC-13 cryptographic protection (FIPS-validated). HIPAA's NPRM makes ePHI encryption at rest and in transit mandatory. FINMA Circular 2023/1 expects strong cryptographic module authentication and communications protection aligned with international baselines. ADHICS V2 mandates AES-256 for PHI at rest and in transit, with HSM or KMS-backed key management and strict key governance. SAMA Domain 3.3.6 mandates AES-256 for data at rest (database and disk encryption) and AES-256 with TLS 1.2 or higher in transit, with HSM or robust KMS for keys.

The post-quantum transition is now the looming deadline. NIST finalised the first post-quantum cryptography standards on 13 August 2024 (FIPS 203 ML-KEM for key encapsulation, FIPS 204 ML-DSA for digital signatures, FIPS 205 SLH-DSA as a hash-based alternative). The CNSA 2.0 milestones require new US national security system deployments to comply with CNSA 2.0 by 1 January 2027, full migration of national security systems by 2030, complete enforcement by end-2031, and all national security systems quantum-resistant by 2035. NIS2's 2026 amendments introduce post-quantum cryptography migration policies targeting completion between 2030 and 2035. The platforms that can rotate algorithms and key types without rebuilding from scratch will pass the migration; the platforms that hardcoded algorithm choices into their storage layer will face a re-platforming project. The companion article on customer-controlled encryption keys covers crypto-agility as a NIS2 expectation in detail.

Audit trails: from "log everything" to "prove the integrity"

Audit-trail integrity is the third converged control and the one with the steepest in-window slope. The companion article on tamper-proof audit trails walks through the cryptographic primitives in depth. The summary for the convergence story is that every framework now requires not just that logs exist, but that the integrity of the log itself is demonstrable. ISO 27001:2022 A.8.15 makes log tampering protection explicit. PCI DSS 4.0.1 Requirement 10.3.2 prohibits modification of audit log files by individuals and 10.3.4 requires file integrity monitoring with alerting. NIST SP 800-53 AU-9(3) names signed hash functions as the recognised cryptographic mechanism. HIPAA's NPRM tightens audit log retention and integrity protection. NIS2 Implementing Regulation 2024/2690 requires protection of logs against unauthorised access and modification; ENISA guidance adds that integrity should be verifiable through cryptographic means where appropriate. FINMA Circular 2023/1 requires comprehensive and reliable logging with integrity protection over a ten-year banking retention period. ADHICS V2 mandates SIEM-integrated logging with protection from unauthorised access, modification, or destruction. SAMA Domain 3.3.14.1 requires event logs to be defined, generated, retained, protected from unauthorised changes, and reviewed regularly.

The convergence on audit-trail integrity is what makes the first two controls measurable. MFA is only as strong as the proof that it actually engaged on every login attempt during the audit window. Encryption is only as strong as the proof that the key was used by whom and when. Both proofs live in the audit trail. A platform that has MFA and encryption but cannot demonstrate the audit trail of either is, in effect, asking the regulator to take the controls on trust. That posture has been retired across the frameworks at the same time the controls themselves became mandatory.

The questions that distinguish "table stakes" from "design intent"

The procurement question has shifted in a specific way. It used to be "do you support MFA, encryption, and audit logs", with checkbox answers acceptable. It is now "can you demonstrate each of the three, on demand, in a way an auditor can verify". A short, uncomfortable checklist for any team evaluating a platform in 2026.

1. MFA enforcement, phishing-resistant by default. Is MFA on every login, including federated identity providers, with phishing-resistant options (FIDO2, WebAuthn, hardware security keys) as the recommended path? Are weak factors (SMS, push without number-matching, email OTP) at least optional-with-warning rather than default? Can the platform produce an audit log of every MFA challenge that fired and every one that did not, with the reason?
2. Encryption with customer-controlled key custody. Is data encrypted at rest with AES-256 and in transit with TLS 1.2 or higher? More importantly, who holds the key? A platform that holds the key has a trust boundary the customer cannot revoke without contacting the vendor. The post-Schrems II EDPB guidance and the companion frameworks have pushed key custody back toward the customer for any sensitive workload.
3. Audit trail integrity, demonstrable by export. Can the platform produce a tamper-evident export of the audit trail for a specific record, for a specific period, with cryptographic verification? The companion article on tamper-proof audit trails covers the primitives.
4. Cryptographic agility for the post-quantum migration. Can the platform rotate algorithms (move from RSA-2048 to ML-KEM, from ECDSA to ML-DSA) without rebuilding from scratch? NIS2 Article 21 expects this; the CNSA 2.0 timeline forces it; the platforms that hardcoded algorithm choices will face a re-platforming project on a deadline.
5. All three exposed as configurable, auditable, and exportable, not as marketing claims. A platform that supports MFA, encryption, and audit logging in production but cannot expose configuration, audit, or export of any of them to the customer has built the controls for itself, not for the customer's regulator.

A platform that answers each with an architectural artefact rather than a paragraph is producing the controls as design intent. A platform that asks for time to "look into the specifics" is producing the controls as marketing surface.

The architectural answer

The three controls becoming table stakes simultaneously is a regulator-driven shift, and the platforms that handle it well treat each of the three as a structural property of the system, not a feature on a roadmap. Novantra was built with this premise: MFA, encryption, and audit are baseline architecture, not features bolted onto a pricing tier.

Mandatory MFA from day one, on every Novantra account type, with phishing-resistant options as the recommended path. Install-administrator MFA at first login with no opt-out. Federated identity provider integration that preserves MFA enforcement rather than treating SSO as an exemption. Hardware security key support (FIDO2 and WebAuthn) at AAL2 and AAL3 grade. Per-organisation password policy and session-binding for the cases where additional factors are appropriate. The companion piece in the registry on MFA as the no-longer-optional baseline covers the implementation detail.

Novantra encrypts by default everywhere sensitive, with customer-controlled keys as the architectural commitment. AES-256 at rest, TLS 1.2 or higher in transit, with the master key wrapped under a provider the customer manages: AWS KMS in the customer's account, Azure Key Vault under the customer's subscription, HashiCorp Vault Transit on customer infrastructure, PKCS#11 hardware security modules under direct customer operation. Per-organisation key isolation so one customer's keys cannot decrypt another customer's data. Crypto-agility designed in so the post-quantum migration is a configuration change, not a rewrite. The companion article on customer-controlled encryption keys covers the architecture in detail.

Novantra's audit stream is a hash-chained, tamper-evident event stream, exportable on demand, verifiable by the auditor without the vendor's cooperation. Append-only events, hash-chained at the leaf, signed Merkle roots over each window, optional external anchoring for the highest assurance tier. WORM-backed storage underneath with retention matching the strictest applicable framework. Verification tooling published and exercisable. The companion articles on continuous evidence and tamper-proof audit trails cover the architecture in detail. For customers whose jurisdiction or threat model requires it, Novantra's Sovereign deployment runs the entire stack inside the customer's own infrastructure.

None of the three is a feature. Each is a structural commitment that becomes load-bearing the moment a regulated buyer signs the contract, because every major framework now expects each of them to be in place, configurable by the customer, auditable by the regulator, and exportable on demand. The eighteen-month convergence window from October 2024 to mid-2025 closed the loop: the buyers' regulators are asking; the buyers are asking their vendors; the vendors either have the architecture for it already, or they will be writing it during their next funding round. The frameworks have moved. The architecture has to follow.