In the space of four weeks, ANSSI (the Agence nationale de la sécurité des systèmes d’information, France’s national cybersecurity authority) dropped three documents that together sketch the shape of EU sovereign cloud doctrine for the next 24 months. On March 17, 2026 it published the Référentiel Cyber France (ReCyF), its translation of the NIS 2 directive into 20 security objectives. On March 19 it opened a public consultation on reference architectures for security supervision. In early April, for the first time, it made the Feuille de route des efforts prioritaires en matière de sécurité numérique de l’État 2026-2027 (2026-2027 roadmap) public rather than internal.
Formally, that last document is addressed to French state administrations. Practically, it’s the preview of what your cloud provider’s next SecNumCloud renewal, your next EUCS (European Cybersecurity Certification Scheme for Cloud Services) audit, and your next Master Services Agreement (MSA) amendment are going to look like. The good news™: the deadlines are clearly stated. The less good news: several of them fall in calendar year 2026, and one (“generic accounts eliminated or traceability reinforced”) is two months away.
What just dropped
The roadmap itself is a PDF of about 440 KB. Public for the first time by deliberate choice, partly because the threat context (described as “heightened and in a degraded geopolitical situation”) warranted a public signal, and partly because several 2025 incidents inside ministry systems made internal-only doctrine look less than adequate. A monthly interministerial committee, the Comité interministériel de suivi de la sécurité numérique (CINUS), will track compliance under ANSSI’s oversight. Ministries have until June 2026 to decline the roadmap into their own internal plans.
ReCyF, published two weeks earlier, is a 20-point catalogue of security objectives mapped against NIS 2 requirements, with a proportionality principle (smaller or less mature entities can aim lower, provided they can document the reasoning). It’s diffused as a work document, since Article 14 of the forthcoming Loi Résilience (the French transposition law for NIS 2) references a “référentiel de cybersécurité” that ReCyF will eventually formally become.
The supervision consultation, open until May 7, 2026, is the narrower track. For context on how those reference architectures will shape what your provider’s Security Operations Center (SOC) must do, see the earlier piece on ANSSI’s supervision doctrine.
Why this reaches your cloud architecture
If you run a bank or an insurer in the EU, the DORA regulation already sits on top of you. DORA Article 1(2) is explicit: it is lex specialis (more specialized, therefore taking precedence) over NIS 2 for financial entities in its scope. A practitioner reading this and thinking “so NIS 2 and ANSSI’s roadmap don’t concern us” is half right and about to be surprised.
The half that’s right: your institution isn’t directly bound by NIS 2. The half that’s about to be surprised: your cloud provider almost certainly is. NIS 2 designates cloud computing service providers and managed security service providers as Essential Entities, a category with the strictest supervisory regime. Which means the ANSSI doctrine reaches your architecture not through a French law binding your Dutch bank, but through the obligations that French law puts on the OVHcloud, Outscale, S3NS, Bleu (when it ships) or Numspot environment your bank is using. Those obligations flow into the provider’s SecNumCloud qualification and into the contract clauses they’ll ask you to sign at the next renewal.
State doctrine becomes private-sector baseline through certification renewals and contract clauses, not through direct regulatory reach.
The harmonization pressure is stronger than it sounds. ANSSI and BSI (the Bundesamt für Sicherheit in der Informationstechnik, Germany’s federal cybersecurity office) published a joint statement in November 2025 committing to joint sovereignty criteria based on the EU Cloud Sovereignty Framework, with the detailed methodology expected in April 2026. SecNumCloud version 3.2 is already aligned to the EUCS “high” assurance level. The emerging pattern is a three-layer stack: EUCS sets the European floor, SecNumCloud and its German equivalent tighten it, and the ANSSI-BSI criteria will add the sovereignty overlay that covers what EUCS chose not to (a topic for a future post). The 2026-2027 roadmap is the operational preview of what tightens.
The five pressure points
Most of the roadmap reads like an administrator’s hardening checklist. Five items, however, translate directly into architectural decisions for any EU cloud workload sensitive enough to be on a SecNumCloud-qualified platform.
Identity: MFA by year-end, generic accounts gone by June
By December 31, 2026, multi-factor authentication must be mandatory on every administrator account for state information systems. By June 2026, every generic account (shared, service, or application accounts with non-named logins) must be either eliminated or have traceability “reinforced” to the level of a named user.
For a financial cloud customer, this matters on two fronts. Your own administrative access to provider consoles needs MFA coverage, which is probably fine. What’s harder to enforce is that the provider’s own privileged personnel, the ones with hypervisor-level or control-plane access, meet the same bar with audit evidence you can actually inspect. This is the kind of clause that has been a lifestyle choice in some MSAs rather than a practice. ReCyF’s identity and access management objective will make it explicit; the roadmap sets the pace.
The generic-account deadline is the harder architectural reshape. Service accounts baked into Terraform modules, shared automation credentials feeding CI pipelines, database application users whose name is literally app_user: all of these need either a traceability layer (named identity behind the service principal, with logged impersonation) or elimination in favour of workload identities. Two months to design and roll that out across a bank’s cloud estate is aggressive. In practice, I’d expect teams to ship the traceability route first and push the workload-identity migration into 2027.
Detection: EDR/XDR as a provider obligation
By the same end-of-2026 deadline, Endpoint Detection and Response (EDR) or Extended Detection and Response (XDR) solutions must be deployed on every workstation and server across administrative systems. The roadmap is explicit that this is a capability, not a checkbox: the detection signal has to be actionable.
For cloud architecture, this is where the supervision doctrine (the one under consultation until May 7) lands in your MSA. If your provider operates the underlying hypervisor and the guest OS is managed, you can’t just install CrowdStrike across your fleet and call it done. The detection architecture has to be jointly defined with the provider. Three patterns are surfacing: the provider emits EDR telemetry and you consume it in your own SIEM; the provider runs a qualified SOC (Prestataire de détection d’incidents de sécurité, PDIS) and you receive alerts; or a federated MSSP chain stitches the two together. These were covered in depth in the supervision doctrine piece; the roadmap deadline turns the architectural choice into a procurement one.
The clause to add to your next MSA: a service level on detection telemetry format, retention, latency, and the right to audit the detection pipeline end to end. Without it, the provider can tell you they “have EDR” and you’ll struggle to prove that means anything operationally.
Messaging: the DMARC question, formally
Before December 31, 2026, messaging system security must be reinforced. The roadmap doesn’t prescribe a specific stack, but read alongside ANSSI’s existing Recommandations pour la configuration d’un serveur de messagerie and the broader DNS security thread in the same document, the direction is clear: DMARC (Domain-based Message Authentication, Reporting, and Conformance) enforcement, SPF and DKIM discipline, DNSSEC on publication domains, and, for state-hosted or sovereign-provider-hosted mailboxes, end-to-end traceability.
For financial services already under DORA’s operational resilience obligations, this is less of a surprise than it sounds. The delta is that providers marketing sovereign email (S3NS Mail, OVHcloud mailing, Scaleway’s managed offerings) will be asked to produce evidence against this baseline at their next qualification. A tenant using a US-headquartered email platform (even on EU infrastructure) is going to have a harder time mapping to the roadmap than one on a SecNumCloud-qualified mail service. Not because the regulation targets a specific product, but because the audit paperwork gets easier.
Post-quantum cryptography: the 2027 onboarding cliff
The roadmap sets the first milestones on ANSSI’s post-quantum cryptography (PQC) trajectory, which the agency has been describing for two years. The ordering is: inventory of cryptographic dependencies across 2026-2027; products qualified by ANSSI will need to include PQC support from 2027 onward; critical use cases migrated to post-quantum algorithms by 2030; intermediate-risk use cases by 2035.
Two architectural consequences. First, the inventory is not optional. Any financial cloud architecture touching sensitive data needs to enumerate every place where asymmetric cryptography is used (TLS termination, signing ceremonies, document encryption, hardware security modules, backup envelopes, JWT issuance, certificate authorities), and start cataloguing the algorithm, the library, and the replacement path. Organizations that haven’t started this in 2025 are not panicking yet but should be. Second, any cloud contract signed in 2026 or later without a PQC transition clause is going to need amending. Providers that can’t articulate a roadmap (“we’ll do it when our cryptography library ships support”) will fail SEAL-4 assessments the moment an architect asks the question.
Homologation on every migration
ANSSI restates in the roadmap what it has said before, with new emphasis: any information system undergoing cloud migration is treated as a new IS, which means a full homologation de sécurité (formal security authorization by a designated authority, usually involving risk analysis, security plan, and acceptance decision). Not a post-facto review, not a reuse of the on-premises homologation, a fresh one.
For migration programs running through 2026, this is the paperwork consequence people forget to plan. If you’re moving a customer-facing payments system from a US hyperscaler region to an EU sovereign provider as part of a DORA third-party risk reassessment, the homologation work is load-bearing: without it, the migration technically leaves your legal posture worse than before. The teams that fit this into the migration timeline up front ship clean; the ones that treat homologation as a compliance stamp at the end end up with a three-month delay and an awkward Slack thread.
A scenario: pan-European lender, late-2026 procurement
Picture a European fintech lending platform, currently on a US hyperscaler’s Frankfurt region, preparing to move tier-1 workloads to a SecNumCloud-qualified provider by the end of 2026 to meet a DORA third-party reassessment. The pattern that tends to emerge: the 2025 MSA templates they’re reviewing are silent on four of the five roadmap pressures. MFA on provider personnel is covered indirectly via ISO 27001 references. EDR telemetry is described as “available upon request.” PQC has one line under “future developments.” Homologation is not mentioned. Messaging is out of scope because it’s a separate contract.
The amendment language that matters before signing: a schedule enumerating which supervision pattern applies (and which PDIS or internal SOC is responsible for each detection stream); a specific clause requiring the provider to publish a PQC roadmap and to support a key-rotation ceremony within 12 months of algorithm availability; a homologation support clause that commits the provider to producing the security documentation the customer’s autorité d’homologation will need; an audit clause over privileged access with ReCyF-mapped evidence standards; and a generic-account clause tying service principals to named identities with logged impersonation.
None of this requires heroics. It requires reading the roadmap PDF before the next quarterly review, not after.
Where this moves SEAL
By end of 2026, the roadmap effectively raises the floor for SEAL-3 compliance. Detection, identity, and messaging architectures that would have been borderline under SecNumCloud 3.2 become insufficient without explicit contract coverage. SEAL-3 is no longer achievable through “hosted in the EU with some tick-the-box certifications”; it requires provider obligations on operational control that can be audited. SEAL-4 gets a new constituent condition from 2027: a demonstrable PQC inventory and transition plan, both by the provider and by the customer using the provider’s cryptographic services. Architectures without that documentation will not hold SEAL-4 under the ANSSI-BSI criteria once they publish.
What to do in the next 30 days
Four items worth putting on a sprint board before May is over.
First, read the roadmap PDF in full (direct PDF, 440 KB; ANSSI publications page). Press coverage captures the headline deadlines but misses nuance on the homologation and messaging sections that press releases don’t repeat.
Second, pull your current cloud provider MSAs and map clauses against the five pressure points. A spreadsheet with five columns is enough. Gaps identified this quarter are cheap to negotiate; gaps identified at renewal time after a compliance audit are expensive.
Third, start the PQC inventory. Even an incomplete list of where asymmetric cryptography lives in your stack beats having to produce one under audit pressure in 2028. For a mid-size European fintech, the first-pass inventory is typically a two-week effort by one senior engineer and one security architect; it gets harder, not easier, the longer it’s postponed.
Fourth, check whether your provider has a position on the ANSSI supervision consultation. The deadline is May 7. Providers with nothing to say publicly are a mild signal that they’re not actively shaping the architecture they’ll be bound by. Providers with a submitted response are easier to audit.
None of this interpretation should be confused with legal advice. Treat the mapping as an architectural reading, and run the contract language past counsel before committing anything to a procurement. The compliance calendar moves faster than intuitions do right now, and the April 2026 window is narrower than it looks.