Austria Software Supply Chain and AI Security Rules: A 90-Day Plan

If your organisation builds, buys or runs software in Austria, the rules that decide what you must prove about it now come from five places: the Network and Information Systems Security Act 2026 (Netz- und Informationssystemsicherheitsgesetz 2026, NISG 2026), which the Austrian legal information system lists as in force from 1 October 2026; the EU's Digital Operational Resilience Act (DORA), supervised in Austria by the Financial Market Authority (FMA); the Data Protection Act (Datenschutzgesetz, DSG) alongside the GDPR, supervised by the Data Protection Authority (Datenschutzbehörde, DSB); the EU Cyber Resilience Act for products with digital elements; and the EU AI Act. The practical answer is the same for all five: know which components are in your software, know which suppliers you depend on, be able to answer "are we affected?" inside the reporting clocks, and keep a record that management signed off.

This guide is for the CISO, AppSec, engineering, GRC, procurement, the data protection officer and the management body in Austrian organisations, and for foreign software makers selling into Austria. The first two thirds work with whatever tools you have; Safeguard enters at "How Safeguard does this".

This is not legal or regulatory advice. Where the post describes a rule, it describes the primary text as published on 25 October 2026. Your supervisor, auditor and counsel decide how it applies to you.

Key takeaways

• The NISG 2026 (BGBl. I Nr. 94/2025) is listed on RIS as in force from 1 October 2026, replacing the NISG 2018. Its competent authority is a new Federal Office for Cybersecurity under the Minister of the Interior (section 3a). Registration is due by the end of December 2026 (section 29(3)).
• Section 32(4)(d) covers supply chain security, including suppliers' development processes; (e) covers vulnerability management and disclosure. Section 33 asks for a self-declaration within twelve months of the registration duty. Section 34 sets 24 hour, 72 hour and one month reports.
• DORA has applied since 17 January 2025; the DORA Enforcement Act (DORA-Vollzugsgesetz, DORA-VG) makes the FMA the competent authority, working with the Oesterreichische Nationalbank (OeNB).
• The CRA's reporting duties for actively exploited vulnerabilities apply from 11 September 2026; the main obligations apply from 11 December 2027.
• The RTR's AI Act timeline, adapted by the AI omnibus, puts Annex III high-risk requirements at 2 December 2027 and Annex I at 2 August 2028.
• Safeguard capabilities covered here, all GA: SBOM generation, SCA with deep transitive dependency scanning, vulnerability management with EPSS and CISA KEV, reachability analysis, CSAF and VEX upload, policies and gates, license compliance, attestation and signing, Package Firewall, TPRM, Trust Center, Portal (SBOM publish and share), the compliance and GRC suite, autonomous remediation (ships switched off), AI-BOM discovery, agent identity, the CLI and local runner, and private VPC, on-prem, air-gapped and Zero AI deployment.

Who this applies to in Austria

Austria is an EU member state, so DORA, the CRA, the GDPR and the AI Act apply directly, and NIS2 arrives through the NISG 2026, whose gazette entry carries the NIS2 Directive's CELEX number, 32022L2555.

Essential and important entities under the NISG 2026. Section 24 sorts organisations into two tiers. Essential entities include, regardless of size, qualified trust service providers, top level domain registries, DNS service providers, federal public administration bodies and entities identified as critical under the EU Critical Entities Resilience Directive, plus large enterprises in the sectors in Annex 1 and medium-sized providers of public electronic communications networks or services. Important entities are large or medium-sized enterprises in the sectors of Annexes 1 and 2 that are not already essential. Section 25 sets the size thresholds and section 26 lets the authority classify an entity regardless of size. The supervisor is the Federal Office for Cybersecurity.

Financial entities under DORA. Section 2 of the DORA-VG lists the entities the FMA supervises, from credit institutions (where supervision is not reserved to the European Central Bank) to insurers, investment firms and fund managers. Section 27 of the NISG 2026 deals with exceptions where a sector-specific EU act such as DORA applies, so a bank's first question is how the two overlap for its own licences.

Suppliers. Most software vendors will never register under the NISG 2026 themselves. They will meet it through their customers, because section 32(4)(d) makes those customers assess "the security of their development processes" (Sicherheit ihrer Entwicklungsprozesse).

The rules, regulator by regulator

The NISG 2026 (Netz- und Informationssystemsicherheitsgesetz 2026)

Status, from the Parliament and RIS pages. The government bill (308 d.B., XXVIII. GP) reached the National Council on 20 November 2025 and, because it contained constitutional provisions, needed a two thirds majority. The National Council adopted it on 12 December 2025, with an amendment, after the committee report (354 d.B.), and the Federal Council dealt with it on 18 December 2025. It was published in the Federal Law Gazette as BGBl. I Nr. 94/2025 on 23 December 2025. Section 51(2) says sections 2 to 45 and the annexes take effect after nine months from publication, on the next first day of a month. The RIS consolidated text lists those sections with an in-force date of 1 October 2026. Sections 2 to 31 of the NISG 2018, the NISV and the QuaSteV ceased to apply at the same time.

Our NISG 2026 deadlines post covers the switchover; this section covers the duties that touch software.

The authority. Section 3a names the Federal Office for Cybersecurity (Bundesamt für Cybersicherheit), the "cybersecurity authority" in the rest of the law, directly under the Federal Minister of the Interior with national competence. Section 11 covers coordinated vulnerability disclosure and section 21 cooperation with the DSB.

Registration (section 29). Entities register electronically, giving contacts, sectors and entity type, member states served, IP ranges where relevant, establishments and size data. Section 29(3) sets the deadline at three months from the law taking effect; later entrants have three months from meeting the conditions. Changes to core details are due within two weeks.

Governance (section 31). The management bodies (Leitungsorgane) must ensure and supervise compliance with the section 32 measures and attend cybersecurity training designed for them; staff must be offered regular training. Section 45(1) makes failing to provide that training an administrative offence.

Risk management measures (section 32). Measures must be appropriate and proportionate, take account of the state of the art and relevant national, European and international standards, and follow an all hazards approach. Section 32(4) lists the minimum content:

• (a) risk analysis and information system security policies;
• (b) incident handling;
• (c) business continuity, backup management, disaster recovery and crisis management;
• (d) supply chain security, including the security aspects of relationships with direct suppliers and service providers, their specific vulnerabilities, the overall quality of their products and cybersecurity practices "including the security of their development processes", and the results of EU coordinated risk assessments;
• (e) security in the acquisition, development and maintenance of network and information systems, including vulnerability management and disclosure;
• (f) policies and procedures to assess the effectiveness of the measures;
• (g) basic cyber hygiene and cybersecurity training;
• (h) cryptography and, where appropriate, encryption;
• (i) human resources security, access control and asset management;
• (j) multi-factor or continuous authentication and secured communications.

Section 32(5) lets the authority set more detailed requirements by regulation, including extending the European Commission's implementing acts under Article 21(5) of NIS2 to other sectors.

Proving it works (section 33). Within twelve months of the registration duty arising, entities send the authority a structured self-declaration (Selbstdeklaration) on the measures they have implemented, "in particular" on the systems they use, supply chain security and the results of their risk analysis. Later, on request, they must prove implementation through an independent body (unabhängige Stelle) within two years, based on an audit no older than two years; valid certificates can cover the operational and organisational parts. Essential entities must show the operational and organisational parts within two months of a request. The first request can come no earlier than two years after the law took effect.

Incident reporting (section 34). Significant incidents (defined in section 35) go to the sector CSIRT, or the national CSIRT where there is none, which forwards them to the authority:

1. an early warning without undue delay and at the latest within 24 hours of becoming aware, saying whether unlawful action or cross-border impact is suspected;
2. an incident notification within 72 hours, with a first assessment of severity and impact and indicators of compromise where available;
3. an intermediate report on request;
4. a final report no later than one month after the notification, covering the cause, the threat type, the mitigation applied and any cross-border impact, or a progress report if the incident is still running.

Section 34(3) also requires informing the recipients of your services without undue delay where the incident affects them.

Fines (section 45). For the listed offences, essential entities face up to EUR 10 million or 2 percent of worldwide annual turnover of the undertaking, whichever is higher, and important entities up to EUR 7 million or 1.4 percent. Late or false registration is a separate offence under section 45(4).

DORA and the FMA

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied directly in every member state since 17 January 2025. Austria's DORA-VG (BGBl. I Nr. 112/2024, published 19 July 2024) gives it effect. The parts that matter for software teams:

• Section 2 DORA-VG makes the FMA the competent authority under Article 46 of DORA for the financial entities it lists.
• Section 5 DORA-VG requires the FMA and the OeNB to work closely together for credit institutions and several other entity types.
• Section 6 DORA-VG has the FMA obtain an OeNB expert opinion before attesting a threat led penetration test under Article 26(7) of DORA.

DORA itself asks financial entities to identify and document ICT assets and their dependencies (Article 8), protect system integrity (Article 9), manage ICT third-party risk with a register of information on every ICT contract (Article 28), and classify and report major ICT-related incidents (Articles 17 to 19). For a bank's software team, that means a component inventory for critical applications, a supplier register tied to contracts, and fast incident classification. The FMA's website did not load for us, so the Austrian details above come from the DORA-VG text on RIS; check the FMA's DORA pages for current circulars.

The Data Protection Act (Datenschutzgesetz, DSG) and the DSB

The DSG applies alongside the GDPR. Section 1, a constitutional provision, gives everyone a fundamental right to secrecy of personal data concerning them where there is an interest worth protecting. Section 18 sets up the DSB as the national supervisory authority under Article 51 GDPR. The GDPR duties that touch software are familiar: security of processing (Article 32), notifying the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours (Article 33), using only processors that give sufficient guarantees (Article 28) and keeping records of processing (Article 30). The DSB runs a data breach notification channel on its website.

The DSG matters here because a compromised component in a system that processes personal data can start the NISG 2026 clock and the GDPR clock at once. Plan for both.

The EU Cyber Resilience Act as it lands in Austria

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. The European Commission says reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027. From September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products. From December 2027, products with digital elements must meet the essential requirements in Annex I, including identifying and documenting components in a software bill of materials and handling vulnerabilities without delay. National market surveillance authorities enforce it. We could not confirm on a primary source which Austrian authority has been designated for the CRA, so check that before you plan your contacts. CERT.at's navigation now groups "NISG 2026/CRA" together, which tells you how closely the national CSIRT expects the two to run.

The EU AI Act and the RTR AI service desk

The AI Act entered into force on 1 August 2024. The RTR's AI service desk, set up under section 20c of the KommAustria Act and section 194a of the Telecommunications Act (BGBl. I Nr. 6/2024), publishes a timeline that reflects the AI omnibus:

We could not confirm on a primary source which Austrian authority is the AI Act market surveillance authority. Either way, the practical work is an inventory of the AI models, services and agents you build or deploy, with a risk tier for each.

What the rules ask of software and open source

Strip the five regimes down and they ask for the same seven things. The table maps each to the evidence a supervisor, auditor or customer usually asks for.

Two points save the most time. First, one inventory serves every regime: the same SBOM answers the self-declaration, the DORA asset question, the GDPR records question and the CRA documentation question. Second, the clocks overlap: one exploited component can start the 24 hour NIS early warning, the GDPR 72 hour notification and a CRA report, and each depends on the same question, which of our products contain it?

Real public incidents in or affecting Austria

The examples below come from CERT.at, Austria's national CSIRT. We describe what CERT.at reported and draw no conclusions about what any affected organisation should have done.

DDoS waves against Austrian organisations, June 2025

On 6 June 2025, CERT.at warned of increasing reports of DDoS attacks against Austrian companies and organisations across many sectors. It could not yet see a sector focus, saw signs of financial motivation in some attacks and thought more than one group might be active. Its advice included checking that processes and technical measures actually work, agreeing DDoS mitigation with your internet provider in advance, keeping contact details offline, reporting to CERT.at and filing an NIS report where required.

Ransomware entering through recruiting themed phishing, May 2026

On 26 May 2026, updated on 28 May, CERT.at reported indications that the Qilin ransomware group was buying initial access from the actors behind the ZipLine phishing campaign and using it for encryption and extortion. CERT.at said it had confirmed cases in Austria and a related incident reported from Switzerland. The campaign targets manufacturing and export oriented mid-sized firms: attackers pose as recruiters, start a long and apparently legitimate exchange through a company's public contact form, and only after days or weeks get the victim to open a prepared ZIP file. CERT.at published lure domains and asked organisations to search at least 90 days of inbound mail for them.

Phishing from compromised Austrian business accounts, July 2026

On 24 July 2026, CERT.at reported a rise in successful phishing sent from compromised email accounts of Austrian companies to the contacts in their address books. Because recipients knew the sender, the mails looked legitimate and passed filters. The goal was to take over cloud office accounts and send the next wave. Its advice after a compromise included resetting passwords, ending sessions, telling partners, checking for data leaving, and considering reports to the DSB, the police and a voluntary NIS report.

None of these is a software dependency compromise. They show the supply chain risk Austrian organisations are actually seeing: trust between business partners used as the way in.

The personas who own the problem

Management body (Geschäftsführung or Vorstand)

Section 31 puts the duty on the board itself. They need a short paper on the entity's tier, registration, the planned self-declaration and the supply chain position, before the end of December 2026 and again before the self-declaration goes out.

CISO

The CISO owns the section 32 measures and the section 34 clocks. They need an inventory that answers "are we affected?" in hours and a runbook naming who calls the CSIRT, now, plus progress against the ten measures for the board.

Head of AppSec or product security (PSIRT lead)

They own letter (e), vulnerability management and disclosure, and for manufacturers the CRA reporting duty that already applies. They need SBOMs per release, triage rules that weigh exploitation, a disclosure contact and recorded "not affected" decisions.

VP or Director of Engineering

They want one process instead of four: a CI step that produces the SBOM, applies dependency and licence rules and records exceptions without slowing releases, in place before customer evidence requests pile up.

Information security officer and GRC lead

They assemble the self-declaration, later the independent body's evidence and, at financial entities, the DORA register of information. They need every requirement mapped to an evidence item, an owner and a date.

Procurement and vendor risk owner

They turn letter (d) and DORA Article 28 into contract clauses, a standard evidence request and continuous monitoring, at every renewal and new contract.

Data protection officer (Datenschutzbeauftragter)

The DPO owns the GDPR side of an incident. Inside the 72 hour window they need to know which systems processing personal data contain the affected component and which processors sit in the chain.

Foreign software makers selling into Austria

You will rarely register, but customers will ask you to prove your development and patching practice, and the CRA applies directly. You need a way to send SBOMs and vulnerability statements on request, and a public security contact.

A practical 30/60/90-day plan

This plan works with or without Safeguard. It assumes you start in late October 2026, with the NISG 2026 registration deadline at the end of December 2026.

Days 1 to 30: scope, register and inventory

1. Decide your tier. Check sections 24 to 26 and Annexes 1 and 2 against your activities and size. Write down the result and the reasoning. If you are a financial entity, ask counsel how section 27 and DORA interact for each licence.
2. Register. If you are in scope, gather the section 29(2) details (sectors, member states, IP ranges, establishments, size data) and register with the Federal Office for Cybersecurity well before the end of December 2026.
3. Brief the management body and record its section 31 training.
4. List products and critical systems with an owner and the repositories, images and services behind each, and generate SBOMs in SPDX or CycloneDX for the most critical, per release.
5. Write the reporting runbook. Name the sector CSIRT or national CSIRT you report to, who sends the 24 hour early warning, who writes the 72 hour notification and who decides on informing service recipients under section 34(3). Add the DSB route for personal data breaches.

Days 31 to 60: suppliers, triage and evidence

1. Rank suppliers. Sort by how critical the service is and how much access they have. For financial entities, tie this to the DORA register of information.
2. Send the evidence request (template below) to the top tier suppliers with a deadline.
3. Set triage rules. Combine severity with exploitation signals (EPSS and CISA's Known Exploited Vulnerabilities catalogue) and with whether the vulnerable code is actually reachable. Agree target fix times per class.
4. Record "not affected" decisions as VEX statements, so the same question does not get re-litigated at 2 a.m.
5. Map the ten section 32(4) measures to evidence items, owners and dates, including the letter (f) metrics you will report to management. This becomes the skeleton of your self-declaration.

Days 61 to 90: gates, monitoring and the evidence pack

1. Add CI rules for the clearest cases: no known exploited critical vulnerabilities in new releases, no unapproved licences. Start them in warning mode, burn down the backlog, then make the clearest ones blocking.
2. Turn on supplier monitoring, so a new critical vulnerability in a supplier's SBOM reaches you without waiting for the next questionnaire.
3. Run a tabletop with the illustrative scenario below, timing how long "which products contain this?" takes.
4. Assemble the evidence pack (tier decision, registration, training records, measures map, SBOMs, supplier register, triage records, runbook) and draft the self-declaration with management approval on record.
5. Publish a security contact and, if you are a manufacturer, confirm your CRA reporting route.

Template: supplier software evidence request

We are subject to the Austrian NISG 2026 (section 32(4)(d), supply chain security) [and DORA Article 28]. For each product or service you provide to us, please send by [date]:

1. A current software bill of materials in SPDX or CycloneDX, per release, with component versions and suppliers.
2. Your vulnerability handling policy, including target fix times by severity and your coordinated disclosure contact.
3. VEX statements or advisories for known vulnerabilities you assess as not affecting the product.
4. A description of your secure development process: dependency rules, code review, build integrity and how you record exceptions.
5. Your incident notification commitment to us, in hours, and any independent audit report covering the service. Please tell us within [x] days of any change that affects these answers.

Decision table: one vulnerability, which clock?

Whether an incident is "significant" or "major" depends on section 35 NISG 2026 and DORA; that call belongs to you and counsel.

Illustrative scenario: a Friday advisory

Illustrative scenario, with invented round numbers. On a Friday afternoon an advisory lands for a widely used open source library, with reports of active exploitation. An important entity runs 40 applications. With SBOMs per release, the team finds the library in 6 within the hour; 2 call the vulnerable function. With no evidence of compromise there is no section 34 report yet, but the team opens an incident record, patches the 2 over the weekend and records "not affected" for the other 4. Without SBOMs, the same team spends the weekend asking application owners what they use, and a 24 hour clock, if it starts, runs out first.

How Safeguard does this

Everything below is described from Safeguard's offering documentation and docs.safeguard.sh as of 25 October 2026. Every capability named is GA. Commands are shown as the docs show them; we did not run them for this post. Safeguard helps a team produce and keep the evidence these regimes ask for; it does not decide whether you comply.

Step 1: Build the inventory with SBOM generation (GA)

1. Connect the repositories and container images you build. Safeguard generates SBOMs (GA) in SPDX and CycloneDX and runs software composition analysis with deep transitive dependency scanning (GA).
2. Where you will not connect a repository, use the Safeguard CLI and its built-in local runner (GA):

# Sign in
safeguard login

# Scan a local directory
safeguard scan --dir .

# Scan an SBOM you already have (SPDX or CycloneDX)
safeguard scan --sbom sbom.json

The docs say that when you scan from the interactive terminal while signed in, the runner uploads the SBOM and findings, never your source.

3. Check SBOMs you receive from suppliers before you rely on them:

safeguard validate sbom.json --strict -o report.json

The docs say validate checks CycloneDX, SPDX and VEX documents against their specifications.

Step 2: Map scans to Austrian and EU frameworks with the compliance and GRC suite (GA)

The compliance and GRC suite (GA) includes framework pages for the regimes in this post:

• EU NIS2 Directive: scan requirements mapped to supply chain security, vulnerability handling and disclosure, the risk analysis inventory, incident reporting readiness, a coordinated disclosure contact and software integrity. The NISG 2026 transposes the same Article 21(2) measures in section 32(4). The page is on unless you switch it off in Compliance › Manage.
• Austria Data Protection Act (DSG): scan requirements for security of processing, integrity and confidentiality, records of processing systems, processor and vendor accountability, breach notification readiness and controller accountability, each checked against the product's SBOM. This page is off until you switch it on in Compliance › Manage.
• EU DORA: scan requirements tied to ICT asset identification with versions, system integrity, the third-party provider register, incident classification readiness and documentation of the ICT risk framework.
• EU Cyber Resilience Act and EU AI Act pages cover the product and AI sides.

These pages use Safeguard's own requirement names, not the regulator's numbering, and there is no separate NISG 2026 page, so map the NIS2 page's evidence to your section 32(4) map.

Step 3: Prioritise with vulnerability management and reachability analysis (GA)

1. Vulnerability management (GA) enriches findings with EPSS and CISA KEV status.
2. Reachability analysis (GA) ranks findings by whether the vulnerable code path is actually called, so work starts with what is reachable and exploited.
3. Those two signals feed the triage rules from days 31 to 60 directly.

Step 4: Record "not affected" decisions with CSAF and VEX upload (GA)

In Integrations, filter by Upload and click Connect on the Upload CSAF/VEX card, so supplier advisories and your own "not affected" decisions sit next to the findings they explain.

Step 5: Enforce rules with policies and gates (GA)

1. Go to Settings → Policies and click Create Policy, or describe the policy in plain English and let Safeguard draft it.
2. Set each policy's action. The docs define three: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent).
3. Approvals run through exceptions: a developer clicks Request Exception, selects the policy and finding, gives a business justification and an expiry date, and submits it for approval. The exception history is kept.
4. License compliance (GA) runs in the same flow.
5. Package Firewall (GA) works at install time and blocks malicious, typosquatted and dependency confusion packages before they reach a build.

Step 6: Request and monitor supplier evidence with TPRM (GA)

1. In TPRM (Third-Party Risk Manager), open the vendor, click Request SBOM, choose the products and a request template, and set a deadline. Bulk Request sends to several vendors at once. Custom templates live in Settings → Request Templates, where you can paste the evidence request above.
2. TPRM monitoring watches supplier SBOMs for new risk. Alerts are set in Settings → Monitoring, with types the docs name, including Critical Vuln and Exploited (a CVE added to CISA KEV).

Step 7: Fix what you own with autonomous remediation (GA, ships off)

For repositories you connect, autonomous remediation opens fix pull requests. It ships switched off, with every category set to Manual, so your team decides what runs on its own and what needs a human.

Step 8: Share evidence with Trust Center and Portal (GA)

1. Trust Center (GA) publishes a page with your frameworks, monitored controls, policies, subprocessors and documents, plus a security contact for vulnerability reports. The docs say publishing is always an explicit action.
2. Portal (the SBOM publish and share product, GA) shares SBOMs with Austrian customers who ask for them under section 32(4)(d).

Step 9: Provenance and AI inventory (GA)

1. Attestation and signing (GA) records build provenance (SLSA provenance and in-toto) with SCAL and LCAL scores for software you build, which supports the "security of development processes" question.
2. AI-BOM discovery (GA) inventories AI models and assets, the starting point for AI Act classification. Agent identity (GA) records which agent holds what access, at what level.

Step 10: Choose a deployment that matches your data rules (GA)

Safeguard's SaaS runs in US, EU and Gov regions; there is no Austrian in-country region. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU. For data that must stay under your control, the GA options are:

• Private VPC or dedicated tenancy, single-tenant and not locked to one cloud provider.
• Full on-prem, the whole platform in your own data centre.
• Fully air-gapped, including the AI models running inside your environment, with signed offline snapshot delivery.
• The local runner, where the CLI pulls the repository on your machine, scans there and sends only encrypted results; source code never leaves your environment.
• Zero AI mode, where the platform runs deterministically with no language model in the loop, or bring your own approved model.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It is not a supervisor, auditor or independent body. Safeguard does not register you, act as an independent body under section 33, or decide whether you comply with any of these regimes.
• It does not file your reports. Section 34, GDPR, DORA and CRA reports are yours to write, sign and submit; Safeguard helps you scope affected products quickly.
• It holds no Austrian or EU certification. Safeguard is not on any government framework or catalog. Its own posture is "SOC 2 Type II audit in progress" and "designed for FedRAMP High". It helps you produce the evidence these regimes ask for.
• It does not host in Austria. SaaS regions are US, EU and Gov. If you need control over where data sits, use private VPC, on-prem, air-gapped deployment, the local runner or Zero AI mode. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU.
• It does not cover the whole of section 32(4). Business continuity, cryptography policy, HR security, multi-factor authentication rollout and secured communications are outside its scope.
• It does not fix software you do not build. When the vulnerable code sits in a vendor appliance, a hosted service or a closed source product, the fix has to come from that vendor. Safeguard helps you track it.
• It does not classify your AI systems. AI-BOM discovery gives you the inventory; whether a system is high-risk under the AI Act is a legal judgment for you and counsel.

Common mistakes

• Waiting for the authority's self-declaration format before collecting evidence. Section 33 gives twelve months, but the evidence it asks about, systems, supply chain and risk analysis, takes most of that time to build.
• Assuming suppliers are out of scope. Letter (d) brings suppliers' development processes into your measures. If you are a supplier, your customers' questionnaires are the NISG 2026 arriving at your door.
• Forgetting the management body. Under section 31, a security plan without recorded board approval and training is incomplete.
• Planning only for the NIS clock. A single incident can also start the GDPR 72 hour clock and, for financial entities, DORA reporting. Put all of them in one runbook.
• Blocking everything on day one. Start CI rules on Warn, fix the backlog, then move the clearest rules to Block.

FAQ

Is the NISG 2026 in force?

The RIS consolidated text lists its sections in force from 1 October 2026. It was published as BGBl. I Nr. 94/2025 on 23 December 2025.

Who supervises NIS2 in Austria?

The Federal Office for Cybersecurity (Bundesamt für Cybersicherheit), set up by section 3a of the NISG 2026 and placed directly under the Federal Minister of the Interior. Incident reports go to the sector CSIRT, or to the national CSIRT where there is none, which forwards them to the authority.

When must entities register under the NISG 2026?

Within three months of the law taking effect, under section 29(3), which puts the deadline at the end of December 2026. Entities that come into scope later have three months from meeting the conditions.

What are the incident reporting deadlines under the NISG 2026?

An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report no later than one month after the notification, under section 34(2).

Does a software supplier have to comply with the NISG 2026?

Usually not directly, unless it is itself in scope. But section 32(4)(d) makes in-scope entities consider their suppliers' development processes, so suppliers will be asked for evidence.

Who supervises DORA in Austria?

The FMA, under section 2 of the DORA-VG, working closely with the Oesterreichische Nationalbank under section 5. For significant credit institutions, some supervision sits with the European Central Bank.

Does the GDPR breach clock run alongside the NIS clock?

It can. If a significant incident also affects personal data, GDPR Article 33 asks for notification to the DSB without undue delay and, where feasible, within 72 hours, in addition to the section 34 reports.

Where can Austrian organisations get guidance on the AI Act?

The RTR's AI service desk (KI-Servicestelle) publishes an AI Act timeline and guidance. Under its current timeline, Annex III high-risk requirements apply from 2 December 2027 and Annex I from 2 August 2028.

Austria's rules all come back to the same question: when a component turns out to be vulnerable, how fast can you find it and fix it? The block below describes the three ways Safeguard closes that gap for the open source you build and ship.

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 shows the local runner. You set up the runner on your own machine, approve it with its device code, then scan from the terminal. For an Austrian team whose source code must stay on its own systems, this is the flow that produces SBOMs and findings for the self-declaration without handing over the repository.

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

The second demo is a real Safeguard 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 advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow is how a team works through the vulnerability management duty in section 32(4)(e) one fix at a time.

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 shows how you choose which tools Claude can use. GRC and security teams can then ask questions of their SBOM and findings data while drafting the self-declaration, with access limited to the tools they approved.

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

Quick check

Sources

• Parliament: government bill 308 d.B., NISG 2026, procedure
• Parliament: committee report 354 d.B., NISG 2026
• RIS: BGBl. I Nr. 94/2025, NISG 2026 (authentic gazette text)
• RIS: NISG 2026, consolidated section 3a with in-force date
• RIS: BGBl. I Nr. 112/2024, DORA-Vollzugsgesetz
• RIS: DSG section 1, fundamental right to data protection
• RIS: DSG section 18, the Data Protection Authority
• Data Protection Authority (DSB)
• European Commission: Cyber Resilience Act
• RTR AI service desk (KI-Servicestelle)
• RTR: AI Act timeline
• RTR: AI Act authorities and bodies
• CERT.at: DDoS attacks on Austrian companies and organisations, 6 June 2025
• CERT.at: Qilin ransomware uses initial access from the ZipLine campaign, May 2026
• CERT.at: more phishing from legitimate Austrian email addresses, 24 July 2026
• CERT.at: current news
• Safeguard docs: EU NIS2 Directive
• Safeguard docs: Austria Data Protection Act (DSG)
• Safeguard docs: EU DORA
• Safeguard docs: EU Cyber Resilience Act
• Safeguard docs: EU AI Act
• Safeguard docs: Safeguard CLI
• Safeguard docs: CLI usage
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Trust Center setup

Related reading: NISG 2026 is in force: deadlines for entities and suppliers.

Try it yourself: download Safeguard or read the Safeguard docs.

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