French public bodies that put particularly sensitive data in a commercial cloud now have a legal duty, not just a policy preference, to use an offer that resists access by non-EU authorities, and SecNumCloud is how that is proven. SecNumCloud is the ANSSI qualification scheme for cloud service providers, set out in a requirements referential (version 3.2) that covers security controls and, since 3.2, protection against extra-European law. Article 31 of the SREN law of 21 May 2024, its implementing decree of April 2026 and an August 2026 arrêté approving the referential have turned it into the reference for State cloud procurement. This guide explains what the scheme requires, how qualification works, what it demands of identity and administration, and how it relates to EUCS, ISO 27001 and other frameworks. It is written for security architects, cloud providers preparing for qualification, and buyers in French public bodies and their suppliers. Status is as checked on 24 October 2026.
Key takeaways
- SecNumCloud 3.2 is still the current referential. ANSSI lists version 3.2 (dated 8 March 2022) with an English translation and an evaluation workbook, and an arrêté of 12 August 2026 approved it as the referential for the SREN Article 31 regime.
- Immunity is a requirement, not a marketing claim. Section 19.6 adds ownership, control and location conditions so that non-EU laws cannot be used to reach customer data; providers headquartered outside the EU or capital-dependent on non-EU players cannot qualify.
- The legal trigger is sensitivity, not size. Article 31 of loi n° 2024-449 applies to State administrations, certain operators and six listed public interest groupings when they process data whose compromise could harm public order, public security, health or life, or intellectual property.
- Administration access is the heart of the controls. Separate provider and customer admin accounts, admin interfaces not exposed to public networks, strong multi-factor authentication and centralised logs retained for at least six months are explicit requirements.
- EUCS has not replaced it. The EU cloud certification scheme remained unadopted in 2026, with sovereignty criteria still disputed, so SecNumCloud (or an EU or EEA certification that is recognised as equivalent) is the route that works today.
What it is and who it applies to
SecNumCloud is a qualification issued by ANSSI (Agence nationale de la sécurité des systèmes d'information) to a specific cloud offer, not to a company as a whole. A qualified offer receives the ANSSI Visa de sécurité and appears in the ANSSI catalogue of certified and qualified products and services, which ANSSI says is updated at least monthly and shows each decision reference and validity dates. The referential covers four activity types: SaaS, PaaS, CaaS (added in 3.2) and IaaS.
Three layers of obligation now sit on top of each other:
| Layer | Instrument | What it does | Who it binds |
|---|---|---|---|
| Policy | Doctrine "Cloud au centre" (circular of 5 July 2021) | Makes cloud the default for new State digital projects; sensitive data on commercial cloud must use a SecNumCloud-qualified offer or equivalent European qualification | State administrations |
| Law | Loi n° 2024-449 of 21 May 2024 (SREN), Article 31 | Requires protection of particularly sensitive data against third-state access not authorised by EU or Member State law | State administrations, certain State operators, listed public interest groupings (GIP) |
| Decree | Décret n° 2026-272 of 14 April 2026 and arrêté of 14 April 2026 | Lists six GIP, defines security and protection measures, sets the derogation procedure | Same bodies, and the private providers serving them |
| Referential | Arrêté of 12 August 2026 approving SecNumCloud 3.2 | Fixes the detailed requirements; conformity shown by ANSSI qualification or an EU or EEA certification of at least equivalent level | Commercial cloud providers serving the bodies above |
The six GIP named in the decree are the Agence du numérique en santé, the Centre d'accès sécurisé aux données, the Centre ressources prévention de la radicalisation, the Collecteur analyseur de données, Modernisation des déclarations sociales and the Système national d'enregistrement de la demande de logement social. Private companies are not directly required to use SecNumCloud by Article 31, but many adopt it voluntarily, and suppliers to the covered bodies will meet it through procurement. Operators of vital importance and NIS2 entities may also be steered towards it by sector rules; check the rules for your sector rather than assuming. See the Data Sovereignty and Residency Guide for the wider sovereign cloud picture.
Derogations: according to the Ministry of Economy legal directorate, a body whose project started before Article 31 took effect may ask its minister for a derogation. The minister has two months to decide, the Prime Minister must validate it, it must be reasoned and public, and DINUM gives an opinion. It lasts at most 18 months from the date a suitable cloud offer becomes available in France, or one year, renewable, where none exists.
Structure and key requirements
The referential follows the shape of ISO/IEC 27001 and 27002, then adds cloud and sovereignty chapters. Only requirements (not recommendations) are checked during qualification (section 3.1).
| Chapter | Topic | Examples of what is checked |
|---|---|---|
| 5 | Security policies and risk management | Risk assessment must list residual risks from non-EU laws that allow collection of customer data without consent, and share the analysis on request (5.3 d, e) |
| 6-7 | Organisation and human resources | Segregation of duties, screening, awareness, leaver process |
| 8 | Asset management | Inventory, ownership, marking, removable media |
| 9 | Access control and identity management | Nominative accounts, annual access review, admin interface separation, MFA |
| 10 | Cryptography | Encryption that prevents data recovery when resources are reallocated (10.1 a); TLS, IPsec and SSH per ANSSI recommendations (10.2); keys and secrets in a security container or separate medium (10.5 c); infrastructure certificates from a CA in an EU member state (10.6 a) |
| 11 | Physical security | Public, private and sensitive zones, access control, maintenance |
| 12 | Operations security | Change management, backups, logging (12.6, 12.7), correlation (12.9), vulnerabilities, administration (12.12), remote maintenance (12.13), outbound flow monitoring (12.14) |
| 13 | Communications security | System mapping, network segregation and monitoring |
| 14-15 | Development and third parties | Secure development, security testing, supplier agreements and monitoring |
| 16-17 | Incidents and continuity | Reporting, evidence collection, continuity testing, client data backup |
| 18 | Compliance | Applicable law, independent reviews (initial, continuous and after major change) |
| 19 | Additional requirements | Service agreement (19.1), data location (19.2), regionalisation (19.3), end of contract (19.4), personal data (19.5), protection against extra-European law (19.6) |
Protection against extra-European law
Section 19.6 is what distinguishes SecNumCloud from a security certification such as ISO 27001 or SOC 2. It works through corporate structure and operations rather than technology alone:
- Ownership and control: limits on the share of capital and voting rights that non-EU entities may hold, individually and collectively, and on their ability to control the provider. Commentators describe caps and a ban on veto rights; read the exact thresholds in the ANSSI text itself before relying on them in a contract.
- Location of data and operations: customer data and the technical data needed to run the service are stored and processed in the EU (19.2), and commentaries on 3.2 describe support and remote maintenance as limited to staff located in the EU.
- Headquarters: a provider whose head office is outside the EU cannot hold the qualification.
- Risk analysis: any residual exposure to non-EU law must be named in the provider's risk assessment (5.3 d) and disclosed to customers on request.
The practical effect is that a hyperscaler region in France does not by itself qualify. Partnership models in which an EU-controlled company operates technology licensed from a non-EU vendor exist for this reason; the qualification attaches to the operator and its offer.
Identity and NHI requirements
Chapter 9 and parts of chapters 10 and 12 are where identity teams will spend most of their effort. The provider's own administrative identities and machine credentials are in scope, and the customer remains responsible for what it deploys on top.
| Clause | Requirement | What it means for identities |
|---|---|---|
| 9.2 b | Nominative accounts | No shared admin logins; each operator and each automation has its own accountable identity |
| 9.4 a | Annual review of user access rights | Include service accounts, API keys and automation roles in the review, not only staff |
| 9.5 b | Account lockout after limited failed attempts | Rate limiting on every authentication endpoint, including APIs |
| 9.5 c | SaaS must offer MFA to end users | Customers must be able to enforce MFA on their tenants |
| 9.6 a, b | Separate provider and customer admin accounts and interfaces | Provider operators cannot use customer-facing consoles to administer the platform |
| 9.6 d | Provider admin interfaces not reachable from a public network | Dedicated admin network, bastion or jump hosts |
| 9.6 f | Strong MFA on provider and customer admin interfaces | Prefer hardware-backed or phishing-resistant factors for operators |
| 10.5 c | Keys and secrets protected in a security container or separate medium | Secrets in an HSM or vault, never in code or configuration files |
| 10.6 a | Infrastructure certificates from an EU-based CA | Machine identities (TLS, mTLS, workload certificates) chain to an EU trust root |
| 12.6 to 12.9 | Logging policy, six-month minimum retention, central storage separate from sources, correlation | Admin sessions and token use must be attributable and kept off the hosts they describe |
- Non-human identities: orchestration platforms, CI/CD runners, backup agents and monitoring tools all hold credentials that can administer the platform. Treat them as privileged under 9.6 and as secrets under 10.5. See the Service Account Security Guide and the Secrets Management Guide.
- Customer-side workloads: SecNumCloud qualifies the provider's offer. Workload identities, federation and key management inside the customer tenant remain the customer's job. See the Cloud Workload Identity Guide.
- Threat model: stolen cloud account credentials (MITRE ATT&CK T1078.004, Cloud Accounts) are the attack 9.6 is written against. MFA on admin interfaces and non-public admin paths are the main defences.
- Privileged operations: session recording and just-in-time elevation for operators are not named in the clauses above but are the usual way providers evidence 9.6 and 12.12. See the Privileged Access Management Guide.
Implementation steps
For a provider, ANSSI describes a sequence that starts well before evaluation. For a buyer, the steps are about selecting, contracting and staying compliant.
Provider route to qualification
- Read the referential and the ANSSI guides it cites, plus the qualification procedure and forms. Download the evaluation workbook (trame d'évaluation v1.0) and use it as your gap assessment.
- Fix the perimeter. Decide which offer (IaaS, CaaS, PaaS or SaaS) is in scope, where its data and administration sit, and which subcontractors it depends on.
- Check eligibility under 19.6 first. Ownership, head office and staffing conditions cannot be fixed by controls; settle them with legal counsel before spending on technical work.
- Contact ANSSI at [email protected] to present the project; a preliminary positioning analysis can be requested.
- File the entry request at [email protected]. Formal entry (milestone J0) is confirmed by letter, after which you may say you are in qualification and appear on ANSSI's list of providers being qualified.
- Run the evaluation with an evaluation centre approved by ANSSI, planning the timetable with that centre.
- Maintain it. Qualification lasts three years, with annual surveillance audits, and must be renewed at the end of the period. Press releases mentioning SecNumCloud must be submitted to ANSSI before publication.
Qualification by composition
A PaaS or SaaS provider can build on an already qualified IaaS. ANSSI's FAQ says the underlying IaaS is then mainly assessed through the service agreement, which reduces evaluation effort, but the qualification is not inherited: the new offer must still go through the process, prove isolation from the underlying platform and from that platform's other customers, and treat loss or non-renewal of the IaaS qualification as a risk in its own register.
Buyer route
- Classify the data against the Article 31 test (public order, public security, health or life, intellectual property). ANSSI stresses that a qualified offer does not replace the customer's own impact study and risk analysis.
- Check the catalogue for the exact offer, its decision reference and validity dates, not just the provider name.
- Contract for the qualified perimeter: the service agreement (19.1), data location (19.2) and end-of-contract terms (19.4) should match what was qualified.
- Plan for exit and loss of qualification. See the Cloud Concentration Risk and Exit Strategy Guide.
- Use the derogation only if eligible, and track its expiry date.
Evidence and assessment
Qualification evidence is a mix of documents, configuration proof and interviews with operators. Prepare the following, mapped to the trame d'évaluation:
- Risk analysis: including the extra-European law residual risks required by 5.3 d.
- Access control evidence: admin account inventory showing nominative accounts (9.2 b), the last annual review (9.4 a), MFA configuration for admin interfaces (9.6 f) and network diagrams proving admin interfaces are not publicly reachable (9.6 d).
- Cryptography evidence: key management design, HSM or vault configuration (10.5 c), CA chain for infrastructure certificates (10.6 a), TLS and SSH configuration against ANSSI recommendations.
- Logging evidence: logging policy (12.6 a), retention settings of at least six months (12.6 c), central log platform separate from sources (12.7 c), correlation rules (12.9).
- Corporate evidence for 19.6: shareholding, voting rights, governance documents and staff location records.
- Independent review records: initial, continuous and post-change reviews under 18.2.
Metrics that show the controls are working:
- Percentage of provider admin accounts that are nominative and MFA-protected (target 100 percent).
- Number of service accounts and API keys with no owner or no review in the last 12 months.
- Log sources forwarding to the central platform, and days of retention available (at least 180).
- Admin sessions originating outside the dedicated admin network (target zero).
- Days until qualification renewal and open findings from the last surveillance audit.
Mapping to other frameworks
SecNumCloud overlaps heavily with ISO 27001 controls but adds requirements that no general standard contains. Use this as a starting point, then check each clause.
| SecNumCloud area | ISO/IEC 27001:2022 Annex A | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|---|
| 9 Access control, admin interfaces | 5.15, 5.18, 8.2, 8.5 | AC-2, AC-6, IA-2 | PR.AA | 5, 6 |
| 10.5 Secrets and keys | 8.24 | IA-5, SC-12 | PR.AA, PR.DS | 3 |
| 10.1 Data at rest | 8.24 | SC-28 | PR.DS | 3 |
| 12.6-12.9 Logging and correlation | 8.15, 8.16 | AU-2, AU-11 | DE.CM | 8 |
| 15 Third parties | 5.19 to 5.22 | SA-9 | GV.SC | 15 |
| 18.2 Independent review | 5.35 | CA-2 | GV.OV | 18 |
| 19.6 Extra-European law | No equivalent (5.31 covers legal requirements generally) | No equivalent | GV.OC (legal context) | No equivalent |
- EUCS: the European Cybersecurity Certification Scheme for Cloud Services, prepared by ENISA under the Cybersecurity Act, was still not in force in 2026. Reporting from March and April 2026 described the sovereignty criteria as the main point of dispute between Member States. Until it is adopted, the decree allows an EU or EEA certification of at least equivalent level, which in practice means another national scheme that ANSSI recognises.
- NIS2: NIS2 allows Member States to require essential and important entities to use certified ICT services. See the NIS2 Directive Guide.
- ISO 27001: an ISO 27001 certificate helps with chapters 5 to 18 but is not accepted in place of qualification. See the ISO 27001 Certification Guide.
- Other cloud schemes: the Cloud Security Alliance CCM and STAR Guide and the FedRAMP Guide cover schemes that buyers often compare with SecNumCloud; neither includes immunity conditions.
Common pitfalls
- Buying the provider, not the offer. Qualification attaches to a named offer and perimeter. A provider with one qualified IaaS may sell other services that are not qualified.
- Assuming data location equals immunity. Hosting in France or the EU does not satisfy 19.6 if the operator is controlled from outside the EU.
- Forgetting machine credentials. Access reviews and MFA programmes that cover only staff leave automation tokens with platform-wide rights out of scope, which is exactly the kind of credential that failed in the PocketOS database deletion, where an over-privileged platform token let an agent wipe production.
- Logs stored on the systems they record. 12.7 c requires central storage on a separate machine; local-only logs fail and are lost in an incident.
- Treating a derogation as permanent. Derogations are time-limited and public; plan the migration from day one.
- Relying on inherited qualification. A SaaS on a qualified IaaS still needs its own qualification and must manage the risk of the underlying offer losing it.
Practitioner checklist
- Confirm whether your data falls under SREN Article 31 and record the classification decision.
- Check the ANSSI catalogue for the exact offer, decision reference and validity dates before contracting.
- For providers, settle 19.6 ownership, head office and staffing eligibility before technical work.
- Inventory every provider admin account, service account and API key; make each nominative or owned, and review annually.
- Enforce strong MFA on all admin interfaces and remove any public network path to provider administration.
- Move keys and secrets into an HSM or vault and chain infrastructure certificates to an EU-based CA.
- Centralise logs on a separate platform with at least six months of retention and active correlation.
- Track qualification expiry, surveillance audit findings and any derogation end date.
- Build an exit plan that covers loss of qualification by your provider or its underlying IaaS.
Standards and references
- ANSSI: SecNumCloud, Prestataires de services d'informatique en nuage, référentiel d'exigences v3.2
- ANSSI: Référentiels de qualification
- ANSSI: FAQ qualification SecNumCloud
- ANSSI: Catalogue of certified and qualified solutions
- Ministère de l'Économie, Direction des affaires juridiques: Article 31 of the SREN law and décret n° 2026-272
- DINUM: La doctrine de l'État, Cloud au centre
- European Commission TRIS: Notification 2025/0041/FR, draft decree on strategic and sensitive data in cloud computing
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Data Sovereignty and Residency Guide · NIS2 Directive Guide · Cloud Concentration Risk and Exit Strategy Guide · Global Cybersecurity Regulatory Map. This guide summarises the SecNumCloud qualification scheme and the related French rules as of October 2026 and is not legal advice.