France software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in France, five sets of rules already reach your code and your suppliers today: DORA for banks and insurers supervised by the ACPR, the EU Cyber Resilience Act for anyone selling products with digital elements, the GDPR as enforced by the CNIL, ANSSI's rules for vital operators and public administrations, and the 2023 military programming law's duty on software publishers to report significant vulnerabilities. The French law that transposes NIS2 is still before the Assemblée nationale on 25 October 2026, so the honest plan is to build the evidence now and map it to the final text when it lands.

This guide takes each regime from its primary source, names the supervisor, lists what it asks of software and open source, and ends with a 30/60/90-day plan that works with any tooling. It is a practical reading of public texts, not legal advice.

Key takeaways

• NIS2 in France is not yet law. The bill on the resilience of critical infrastructure and the strengthening of cybersecurity (projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité) passed the Senate on 12 March 2025. The Assemblée nationale's special committee adopted its text on 10 September 2025. No plenary vote at the Assemblée appears on either chamber's dossier as of today.
• DORA already applies to French banks, insurers, payment institutions and investment firms, from 17 January 2025. The ACPR supervises most of them. ICT third-party risk (Articles 28 to 30) and major incident reporting (Article 19) are where software supply chain work lands.
• The EU CRA reporting clock started on 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents under Article 14. The full product obligations, including the SBOM duty in Annex I Part II, apply from 11 December 2027.
• French software publishers already have a national reporting duty. Article L2321-4-1 of the Defence Code, added by the 2023 military programming law, requires publishers to tell ANSSI about significant vulnerabilities in their products and to inform their users.
• The CNIL fines security failures. In January 2026 it fined Free Mobile and Free a combined 42 million euros, and France Travail 5 million euros.
• AI rules are phased. The Commission says AI Act high-risk obligations now start on 2 December 2027 (Annex III) and 2 August 2028 (Annex I). The CNIL finalised its AI development recommendations, including security, in July 2025.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and KEV, reachability analysis, policies and gates, the Compliance and GRC suite with framework pages for ANSSI RGS, NIS2 and the EU CRA, TPRM SBOM requests, CSAF and VEX upload, Trust Center, AI-BOM discovery, AI Gateway, MCP Guardrail, agent identity, autonomous remediation (ships switched off), the local runner, Zero AI mode, and private VPC, on-prem and air-gapped deployment.

Who this applies to in France

France has more overlapping software security rules than most EU countries, because national defence law, administrative law and EU law each add a layer. The quickest way to see your exposure is to ask which of these boxes you sit in.

Regulated finance. Credit institutions, insurers and reinsurers, payment and e-money institutions and investment firms fall under DORA, Regulation (EU) 2022/2554. The Autorité de contrôle prudentiel et de résolution (ACPR), which sits within the Banque de France, supervises banks, insurers and payment institutions. The Autorité des marchés financiers (AMF) covers the market side, such as asset managers. Your ICT providers, including SaaS and software vendors, are drawn in through contracts and the register of information.

Operators of vital importance and critical infrastructure. The opérateurs d'importance vitale (OIV) designated under the Defence Code run systems of vital importance in sectors such as energy, transport, health, water, telecoms and finance. ANSSI sets and checks their cyber rules. When the resilience bill passes, a much wider group of "essential" and "important" entities under NIS2 will join them, also supervised by ANSSI for cyber.

Public administrations and their suppliers. State administrations, local authorities and public bodies must follow the Référentiel général de sécurité (RGS) for systems that exchange information electronically with users or other administrations, and must formally accredit those systems (homologation). The "cloud au centre" doctrine adds hosting rules for state digital services. Suppliers feel these rules through tender requirements and contract clauses.

Software publishers and product makers. Any publisher whose products are supplied in France has the Defence Code reporting duty. Any manufacturer that places a product with digital elements on the EU market, from a connected device to installable software, is inside the EU CRA. ANSSI is France's national CSIRT and the natural contact point for both.

Anyone processing personal data. That is nearly everyone. The Commission nationale de l'informatique et des libertés (CNIL) enforces GDPR Article 32 security duties and Article 33 breach notification, and publishes guidance on AI system development.

Organisations building or deploying AI. The EU AI Act applies directly, and the CNIL is central for anything involving personal data.

The rules, regulator by regulator

Each status below was checked on 25 October 2026 against the regulator's own page, the official legislative dossier or the EU text.

NIS2 and the resilience bill (ANSSI)

NIS2, Directive (EU) 2022/2555, had to be transposed by 17 October 2024 under its Article 41. France chose a single bill to transpose three EU texts at once: the Critical Entities Resilience Directive, NIS2, and the parts of DORA that need national law. The government filed it in the Senate on 15 October 2024 under the accelerated procedure.

Here is the status on the official dossiers:

So the French NIS2 law is not in force. ANSSI is designated in the bill as the national cyber authority, and it already acts as the national CSIRT (CERT-FR). A deep account of the bill's structure, entity numbers and ANSSI's preparatory work is in our earlier post on the French NIS2 transposition bill; this guide does not repeat it.

What matters for planning is that the directive's own text fixes the substance the French law must carry:

• Article 20 makes management bodies approve the cybersecurity risk measures, oversee them, and follow training.
• Article 21(2) lists the minimum measures, including risk analysis (a), incident handling (b), business continuity (c), supply chain security including relationships with direct suppliers (d), security in acquisition, development and maintenance, including vulnerability handling and disclosure (e), assessment of effectiveness (f), cyber hygiene and training (g), cryptography (h), HR security and access control (i), and multi-factor authentication (j).
• Article 21(3) tells entities to take into account each supplier's vulnerabilities, the overall quality of its products and cybersecurity practices, including secure development procedures.
• Article 23(4) sets the reporting clock for significant incidents: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month.
• Article 34 sets maximum fines of at least 10 million euros or 2% of worldwide turnover for essential entities, and 7 million euros or 1.4% for important entities.

None of that will change in the French text in a way that makes software inventories, supplier evidence or a fast impact assessment less necessary.

ANSSI's RGS and homologation (public sector)

The RGS rests on Decree no. 2010-112 of 2 February 2010, which applies the 2005 ordinance on electronic exchanges between users and administrative authorities. Version 2.0 of the RGS was approved by an order of 13 June 2014 and took effect on 1 July 2014. It sets the rules administrative authorities must follow for the security of their information systems, including cryptography (Annex B1), authentication, electronic signatures and timestamping, and the use of qualified products and providers.

The central idea is homologation de sécurité: a formal decision by the authority, based on a risk analysis and a documented file, that a system meets its security objectives and that the residual risks are accepted. ANSSI's guidance treats it as a management decision, not a technical certificate. In practice the homologation file asks you to describe the system, including its software components, the risks, and how the system will be kept secure over time (maintien en condition de sécurité).

A public buyer will therefore ask suppliers for what goes into its file: what the product is made of, how vulnerabilities are handled, and how updates ship.

SecNumCloud and the "cloud au centre" doctrine (public data)

SecNumCloud is ANSSI's qualification scheme for cloud service providers. The state's "cloud au centre" doctrine was introduced by circular no. 6282-SG of 5 July 2021 and updated in 2023. As a written question published by the Assemblée nationale summarises it, the doctrine makes cloud the default hosting mode for the state's digital services, which must be hosted on one of the state's two internal interministerial clouds or on a SecNumCloud-qualified commercial offer, with trusted hosting for sensitive data.

Two consequences follow for software teams. First, if you sell a cloud service that will hold sensitive state data, the buyer may require SecNumCloud qualification, and no amount of SBOM evidence replaces that. Second, if you sell software the agency will run inside its own qualified environment, your deployment model matters more than your hosting: the agency needs software that can run where its data already lives.

Operators of vital importance (OIV) under the military programming laws

The 2013 military programming law added Articles L1332-6-1 and following to the Defence Code. OIV must apply the security rules set by the Prime Minister to their systems of vital importance (SIIV), report incidents affecting those systems to ANSSI, and accept security audits. The detailed rules are set by sector orders that are not all public. In practice OIV teams already keep a mapped inventory of SIIV components, run qualified audits, and have an incident line to ANSSI.

Software publishers: the Defence Code vulnerability duty

The 2024 to 2030 military programming law (Law no. 2023-703 of 1 August 2023) added Article L2321-4-1 to the Defence Code. It requires software publishers, when they learn of a significant vulnerability in one of their products, or of an incident that could significantly affect a product, to notify ANSSI with an analysis of causes and consequences, and to inform their users within a deadline ANSSI sets. It reaches products supplied in France, or to companies headquartered or controlled in France, so foreign publishers are inside it too. Decree no. 2024-421 of 10 May 2024 added the implementing rules (Articles R2321-1-16 to R2321-1-19), including the criteria for judging whether a vulnerability is significant.

This is easy to miss because it predates the CRA and is not branded as supply chain regulation. It means a French or France-facing software publisher already needs what the CRA will later demand at EU scale: a way to tell, quickly, which products and versions carry a given vulnerable component, and a channel to tell customers.

DORA and the ACPR (banks, insurers, payment firms)

DORA applies from 17 January 2025. The ACPR has published supervisory material on it, including early findings on the register of information and incident reporting after the first months of reporting. The articles that matter most for software:

• Articles 5 to 16, ICT risk management, with protection (Article 9), detection (Article 10) and response and recovery (Article 11).
• Article 8 is the inventory article. Financial entities must identify and classify their ICT assets and map the dependencies between them, including those supported by third parties.
• Article 19 requires reporting of major ICT-related incidents to the competent authority. The timelines are set in a delegated regulation: an initial notification within hours of classifying an incident as major, an intermediate report and a final report on fixed deadlines. Read the delegated text for the exact clock that applies to your entity.
• Article 28 sets the principles for ICT third-party risk, including Article 28(3), the register of information on all contractual arrangements with ICT third-party service providers.
• Article 30 lists the key contractual provisions, including security, audit and access rights, and exit strategies.

For a bank's software supply chain, this means two practical streams. Your own applications need an inventory and a vulnerability process you can show the ACPR. Your vendors need contracts and evidence that let you populate the register and assess concentration and substitutability.

The CNIL: GDPR security and AI guidance

The CNIL enforces GDPR Article 32 (security of processing), Article 33 (breach notification within 72 hours where feasible), and Article 28 (processor obligations, which is where software vendors who process personal data on your behalf come in). It also issues practical guidance.

On AI, the CNIL published its first recommendations on developing AI systems on 8 April 2024 and finalised the series on 22 July 2025, with sheets on applying the GDPR to models, on annotating training data and on the security of AI system development. The security sheet sets out the risks and measures to consider so AI systems are developed in a secure environment. The CNIL also runs PANAME with ANSSI, a project building tools to test whether a model processes personal data.

The EU AI Act

The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024. The European Commission's AI Act page states the current timeline after the AI Omnibus, which entered into force on 27 July 2026:

For supply chain work, providers of high-risk systems will need technical documentation describing components, models and data, and deployers need to know which AI systems they run at all.

The EU Cyber Resilience Act

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. The Commission's CRA page confirms that reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027, and that the Commission published practical guidance on 27 July 2026.

• Article 13 covers manufacturer obligations, including due diligence when integrating third-party components, open source included.
• Article 14 covers reporting. Manufacturers must report actively exploited vulnerabilities and severe incidents through the single reporting platform, starting with an early warning within 24 hours, then a notification within 72 hours, then a final report. In France, ANSSI runs CERT-FR, the national CSIRT.
• Annex I Part I sets essential cybersecurity requirements, including shipping without known exploitable vulnerabilities and protecting integrity.
• Annex I Part II sets vulnerability handling requirements, starting with Part II(1): identify and document the vulnerabilities and components in the product, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.
• Annex VII covers technical documentation, which must be kept for at least ten years after the product is placed on the market or for the support period, whichever is longer.

French manufacturers that sell into the EU therefore have a live reporting duty now and a full product duty in a little over 13 months.

What the rules ask of software and open source

Strip away the labels and the French rules converge on the same small set of software capabilities. This table maps each requirement to the evidence a supervisor, an auditor or a public buyer usually asks for. It describes the shape of the evidence; the exact request depends on the authority and your sector.

Almost every row starts with an inventory, and the clocks are short: NIS2, the CRA and DORA all expect a first report within about a day. That is only possible if "are we affected" is a query, not a project.

Real public incidents in or affecting France

The examples below come from official decisions. They are listed for what the authority found, not for any wider conclusion.

Free and Free Mobile, breach in October 2024, CNIL fines on 13 January 2026. The CNIL states that in October 2024 an attacker got into the companies' information systems and accessed personal data relating to 24 million subscriber contracts, including IBANs for people who were customers of both companies. After more than 2,500 complaints, the CNIL ran an inspection and found failures of several GDPR obligations. It fined Free Mobile 27 million euros and Free 15 million euros, citing security measures it judged inadequate.

France Travail, CNIL fine on 22 January 2026. The CNIL fined France Travail, the public employment service, 5 million euros for failing to ensure the security of job seekers' data, following an incident in early 2024. The decision included an injunction backed by a daily penalty. The CNIL's sanctions page records that, by a deliberation of 23 September 2026, it closed that injunction without collecting the penalty, given the steps France Travail had taken.

Neither decision is about an open source package. Both show the CNIL treating security as an enforceable GDPR duty, which makes Article 32 evidence (what measures you had, and that they were in place) as important as any cyber-specific regime.

We found no French case in the last three years where an official source attributes an incident to a specific compromised open source dependency, so we have not invented one. CERT-FR publishes alerts and advisories on vulnerabilities affecting products used in France, and those are the right feed to watch.

The personas who own the problem

The CISO (RSSI). Owns the risk picture the board sees and the incident line to ANSSI or the ACPR. Needs an answer to "are we affected" within hours, a defensible view of supplier risk, and a plan that survives the final NIS2 text. Triggers: a board review, an ACPR inspection, a CERT-FR alert, an OIV audit.

Head of AppSec or product security. Owns the vulnerability backlog and, for publishers and manufacturers, the CRA and Defence Code reporting duty. Needs SBOMs generated on every release, a triage order that puts exploited issues first, and a disclosure process. Triggers: 11 September 2026 has already passed, so the CRA Article 14 clock is live; an incoming vulnerability report from a researcher; a customer asking for an SBOM.

VP or director of engineering or platform. Owns release speed and the pipeline. Needs one process that satisfies the CRA, DORA and a public buyer's homologation file, not three. Triggers: a public tender, a bank customer's DORA addendum, a release blocked by late review.

GRC and regulatory affairs (conformité). Owns the mapping between rules and evidence. Needs control mappings by article (NIS2 Article 21, DORA Articles 8 and 28, CRA Annex I), retained evidence, and a clean answer for each auditor. Triggers: the DORA register of information submission, an ACPR or AMF request, an RGS homologation renewal, the final vote on the resilience bill.

Procurement and vendor risk (achats). Owns supplier selection and contracts. Needs a supplier register, standard clauses on security, audit and SBOM delivery, and a way to request evidence from many vendors. Triggers: DORA contract reviews, a vendor incident, a tender with hosting requirements.

The DPO. Owns GDPR compliance and the 72-hour breach clock to the CNIL. Needs data flow maps, processor contracts, and evidence that security measures were actually in place. Triggers: a breach, a CNIL inspection, a new AI project that processes personal data.

A practical 30/60/90-day plan

This plan assumes no particular tool. It is written for a mid-sized French organisation that falls under at least two of the regimes above. Adjust the scope, not the order.

Days 1 to 30: inventory and ownership

1. Decide which regimes apply. Fill in a one-page applicability sheet: DORA (yes or no, which supervisor), OIV status, likely NIS2 category under the bill (essential, important or out of scope), public sector supplier or not, CRA manufacturer or not, Defence Code publisher or not. Have legal sign it.
2. Name owners for each clock. NIS2 Article 23 and CRA Article 14 (24 hours), DORA Article 19 (hours after classification), GDPR Article 33 (72 hours), Defence Code L2321-4-1 (per decree). Put a named person and a deputy against each.
3. Build the system and product list. List every application you build, every product you ship and every critical system you buy. Mark which ones are in scope for each regime.
4. Generate SBOMs for the top tier. Start with products sold in the EU and systems that support critical functions. Use SPDX or CycloneDX, generate from the build, not by hand, and store each one with its version and date.
5. Start the supplier register. For DORA entities this is the register of information. For everyone else, a sheet with supplier, service, criticality, contract date, security clauses present or not, and whether you hold an SBOM or attestation.
6. Inventory AI use. List the AI models, APIs and agent tools in use, who owns each, and whether personal data flows through them.

A simple applicability sheet to use today:

Days 31 to 60: vulnerability handling and suppliers

7. Connect SBOMs to vulnerability data. Match components against advisories and record EPSS and the CISA Known Exploited Vulnerabilities catalogue, so exploited issues come first.
8. Write the triage rule. For example: exploited and reachable, fix or mitigate in days; critical but not exploited, fix in the next release; everything else, scheduled. Write down who can grant an exception and for how long.
9. Add a release gate. Block releases that introduce a known exploited vulnerability; warn on everything else. Record every exception with its approver and expiry.
10. Publish a disclosure policy. A security contact, a policy page, and a template for advisories. For CRA manufacturers and Defence Code publishers, add the internal step that decides whether a vulnerability is reportable.
11. Request evidence from critical suppliers. Ask your top suppliers for an SBOM or equivalent attestation, their vulnerability handling process, and their incident contact. Track the requests and the gaps.
12. Run one tabletop. Pick a plausible scenario, such as a vulnerable library in a product you ship to French customers, and walk the 24-hour clock end to end.

Days 61 to 90: evidence, AI controls and sovereignty

13. Map controls to articles. For each regime, map your controls to the article or annex point and link the evidence. Keep the NIS2 mapping against the directive's Article 21 until the French text is final.
14. Set AI controls. For each AI system, record its model source, data flows and access. Put guardrails on prompts and outputs where personal data or sensitive data is involved. Control which tools agents can use.
15. Decide deployment for sensitive work. For state data, sensitive code or a buyer who will not allow code to leave its network, choose an architecture that runs inside the boundary: self-hosted, private cloud, or a local scanner that sends only results.
16. Prepare the evidence pack. One folder per regime with SBOMs, vulnerability decisions, gate results, supplier evidence and the incident runbook. This is what you hand to the ACPR, an auditor, an OIV audit team or a public buyer.
17. Set the recurring rhythm. SBOMs on every release, weekly triage, monthly supplier review, quarterly tabletop.
18. Watch the Assemblée. When the resilience bill passes, compare the final text and ANSSI's implementing rules against your Article 21 mapping, and adjust.

Common mistakes

• Waiting for the French NIS2 law. The directive's Article 21 and 23 duties are fixed. Waiting buys nothing and leaves the inventory work for the week the law is published.
• Treating DORA as a contract exercise only. The register and the clauses matter, but Article 8 also requires you to map your own ICT assets and dependencies.
• Forgetting the Defence Code publisher duty. Many French software companies prepare for the CRA and miss the reporting duty they already have.
• Producing SBOMs once. An SBOM from last quarter cannot answer this morning's CERT-FR alert. Generate them on every release.
• Confusing hosting rules with software rules. SecNumCloud and cloud au centre govern where sensitive state data is hosted. They do not replace vulnerability handling in the software that runs there.
• Assuming AI is someone else's problem. The CNIL's AI security guidance and the AI Act both expect you to know what AI you run. Shadow AI in code and SaaS is common.

How Safeguard does this

Everything in the plan above works without Safeguard. This section shows how the same steps run in Safeguard, using only what Safeguard's documentation describes. Every capability named here is generally available (GA).

1. Turn on the French and EU framework pages. In the Compliance and GRC suite (GA), the ANSSI RGS, NIS2 and EU CRA frameworks are on in a workspace unless you switch them off under Compliance › Manage. Each framework page lists the requirements a scan decides, plus catalogue controls you evidence with tests, uploads, policies or attestations.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) builds the full component inventory. Each scan is checked against the framework requirements, for example FR-RGS-HOMOLOG (a timestamped SBOM for the homologation file) and FR-RGS-MCS (versions recorded so maintaining security is auditable) on the RGS page, NIS2-21.2D (supply chain) on the NIS2 page, and EU-CRA-II1 (an SBOM of top-level dependencies) on the CRA page.
3. Scan without sending source code. For teams that will not grant repository access, the local runner (GA) is part of the Safeguard CLI. As the docs show, you install it with the one-line installer, run safeguard, type /login, and the machine starts polling for work. It runs each scan locally and uploads only the SBOM and findings, never the source code. All traffic is outbound HTTPS that the runner opens. For headless use the docs show:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo
# Is it running, and what is it doing
safeguard runner status
# Drain in-flight work and stop
safeguard runner stop

4. Prioritise what is exploited and reachable. Vulnerability management (GA) matches components against advisories and adds EPSS and CISA KEV context. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which is how you meet a 24-hour clock without drowning in findings.
5. Gate releases and record exceptions. Policies and gates (GA) are set under Settings › Policies with a visual builder or YAML. Each policy's action is Block, Warn or Notify. When a legitimate exception is needed, a developer requests one with a business justification and expiry date, approvers decide, and the audit trail is recorded. In CI, with policy outcomes on, the docs show a job failing when a gate fails:

safeguard ci scan --wait --fail-on-gate <gate>

6. Collect evidence from suppliers. TPRM (GA) keeps the vendor directory with contracts, SLAs and risk tiers. Its SBOM requests let you send single or bulk requests from a template that sets SPDX or CycloneDX format and a deadline, track status from Sent to Validated, send automatic reminders, and validate each submission for format and completeness before it is scanned. That is the evidence trail behind a DORA register entry or a NIS2 Article 21(2)(d) control.
7. State what is and is not affected. CSAF and VEX upload (GA) lets you hold and share exploitability statements, which helps when a customer or ANSSI asks whether a published vulnerability affects your product.
8. Fix, with a human in charge. Autonomous remediation (GA) can open tested, policy gated fix pull requests, singly or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.
9. Inventory and govern AI. AI-BOM discovery (GA) inventories AI assets across code, cloud and SaaS. AI Gateway (GA) puts a guardrail proxy in front of model traffic for prompt injection, jailbreak and PII egress. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access, at what level. These map to the AI inventory and access steps in the plan.
10. Share posture with buyers. Trust Center (GA) publishes posture and documents such as SBOMs and VEX to customers, and helps answer security questionnaires.
11. Choose where it runs. Safeguard's SaaS is multi-region across US, EU and Gov regions; no France-specific region is offered or implied. For residency, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped with the AI models running inside your environment and signed offline snapshot delivery. Zero AI mode (GA) runs the whole platform deterministically with no LLM in the loop, and bring your own model (GA) is available for teams with an approved model list. Safeguard states that customer code, SBOMs and telemetry are not used to train shared models.

Safeguard's posture wording is limited to what its Trust Center says: SOC 2 Type II audit in progress, and designed for FedRAMP High. Safeguard does not claim any French or EU qualification, including SecNumCloud.

What Safeguard does not do

• It does not make you compliant. Safeguard helps you produce and keep the evidence the French and EU rules ask for. The decision that a system is homologated, that an incident is significant, or that a vulnerability is reportable stays with your organisation and your authorities.
• It does not report to ANSSI, the ACPR or the CNIL for you. It helps you answer "which products and versions are affected" quickly. Filing the early warning, the notification and the final report is your team's job, in the channel the authority sets.
• It is not a SecNumCloud-qualified cloud. If a contract or the cloud au centre doctrine requires a SecNumCloud-qualified provider, Safeguard's SaaS does not satisfy that. The on-prem, air-gapped and local runner options let you run the software inside an environment that is already qualified or approved.
• It does not write your contracts or legal analysis. DORA Article 30 clauses, GDPR Article 28 processor terms and the applicability decision under the resilience bill need your legal team.
• It does not fix vendor appliances or hosted services. When a vulnerability sits in a product you buy rather than build, the fix comes from that vendor. Safeguard helps you track the request and the evidence.
• It does not replace your incident response. Containment, forensics and communication with affected people remain your processes.

FAQ

Is NIS2 in force in France?

Not as French law on 25 October 2026. The resilience bill that transposes NIS2 was adopted by the Senate on 12 March 2025, and the Assemblée nationale's special committee adopted its text on 10 September 2025, but no Assemblée plenary vote is recorded on the official dossiers. The directive's substance is fixed, so most organisations prepare against Articles 21 and 23 now.

Who supervises cybersecurity under NIS2 in France?

The bill designates ANSSI as the national cybersecurity authority. ANSSI already runs CERT-FR, the national CSIRT, and supervises the cyber rules for operators of vital importance.

Does DORA apply to French banks and insurers now?

Yes. DORA has applied since 17 January 2025. The ACPR supervises banks, insurers and payment institutions for it, and the AMF covers market participants under its remit.

When do French manufacturers have to report under the EU CRA?

Since 11 September 2026 for actively exploited vulnerabilities and severe incidents, under Article 14, with an early warning within 24 hours. The full product requirements, including the SBOM in Annex I Part II(1), apply from 11 December 2027.

What is the French software publisher vulnerability duty?

Article L2321-4-1 of the Defence Code, added by the 2023 military programming law, requires publishers to notify ANSSI of significant vulnerabilities in their products, or of incidents that could significantly affect them, and to inform users. It applies to products supplied in France, including by foreign publishers.

Does the RGS require an SBOM?

The RGS does not use the word. It requires homologation based on a risk analysis and a file that describes the system, and it requires keeping the system secure over time. A dated software component list is the practical way to show both.

What is SecNumCloud and do I need it?

It is ANSSI's qualification for cloud providers. Under the cloud au centre doctrine, state digital services must be hosted on an interministerial cloud or a SecNumCloud-qualified offer. Software running inside such an environment does not itself need the qualification; a cloud service hosting the data does.

What does the CNIL expect for AI security?

Its recommendations on developing AI systems, finalised on 22 July 2025, include a sheet on the security of AI development. It expects the training data, the pipeline and the model to be treated as assets to protect, alongside the usual GDPR duties.

When do AI Act high-risk obligations start?

According to the European Commission, after the AI Omnibus, high-risk obligations start on 2 December 2027 for Annex III systems and on 2 August 2028 for Annex I products. Prohibitions have applied since 2 February 2025 and general purpose AI model rules since 2 August 2025.

Every French regime above comes back to the same question: when a vulnerable component is named, how fast can you find it and fix it. The block below sets out the ways Safeguard closes the gap between a disclosure and a fixed build, including when upstream has not shipped a fix yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan. The same flow is how a French publisher closes a reportable vulnerability with a human approving each change.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. This is the option for public sector and banking teams that will not let source code leave their network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For teams following the CNIL's AI security guidance, it shows what scoped agent access looks like in practice.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Senate legislative dossier: resilience of critical infrastructure and strengthening of cybersecurity bill
• Assemblée nationale legislative dossier for the same bill
• Directive (EU) 2022/2555 (NIS2), EUR-Lex
• Regulation (EU) 2022/2554 (DORA), EUR-Lex
• ACPR: Digital Operational Resilience Act (DORA)
• European Commission: Cyber Resilience Act
• Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
• European Commission: AI Act regulatory framework and timeline
• CNIL: sanction of 42 million euros against Free Mobile and Free
• CNIL: sanctions listing, including France Travail
• CNIL: finalisation of recommendations on developing AI systems
• ANSSI: the Référentiel général de sécurité (RGS)
• Assemblée nationale: written question no. 1692 on the cloud au centre doctrine (PDF)
• Légifrance: Defence Code Article L2321-4-1
• Légifrance: Decree no. 2024-421 of 10 May 2024
• Safeguard docs: France ANSSI RGS framework
• Safeguard docs: EU NIS2 framework
• Safeguard docs: EU Cyber Resilience Act framework
• Safeguard docs: Local Runner
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: Deployment options

Related reading: the French NIS2 transposition bill in detail, Germany and France sovereign cloud and AI rules explained, and Mistral and European sovereign AI compute.

To try the flows above, download Safeguard and read the Safeguard documentation.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.