DORA ICT Third-Party Risk: What the Axios Supply Chain Attack Means for Your Register of Information

Last updated: April 2026

On March 31, 2026, attackers compromised the npm account of the lead maintainer of Axios, a JavaScript HTTP client library with roughly 100 million weekly downloads. They published two poisoned versions (1.14.1 and 0.30.4) containing a hidden dependency that silently installed a remote access trojan on Windows, macOS, and Linux machines. Google attributed the attack to a North Korea-linked threat actor. Microsoft confirmed. The malicious versions were live for approximately three hours before removal.

Three hours. No code change to Axios itself. Just a new dependency added to the package manifest. That was enough to potentially compromise every CI/CD pipeline, developer machine, and production server that ran an automated package update during that window.

If your firm uses any web-facing application, internal dashboard, API gateway, or client portal built with JavaScript, there is a reasonable chance Axios sits somewhere in your dependency tree. And if it does, this incident has direct implications for your DORA ICT third-party risk management, your Register of Information, and your ICT incident reporting obligations.

Related reading: DORA Register of Information: What Luxembourg Firms Need to Know

What Happened: The Axios Compromise in 90 Seconds

The attackers did not modify the Axios source code. They compromised the maintainer’s npm account and added a single new dependency called “plain-crypto-js” to the package manifest. This dependency contained an obfuscated script that executed automatically during npm installation via the postinstall lifecycle hook. No developer interaction required.

The script detected the operating system of the host machine and downloaded a platform-specific payload from an attacker-controlled server. On Windows, a PowerShell-based trojan. On macOS, a native binary disguised as a system process. On Linux, a Python backdoor. All three variants established persistent command-and-control connections, enabling the attacker to steal credentials, enumerate directories, and execute arbitrary commands.

The attack also included anti-forensic measures. The malicious script attempted to delete itself and restore the original package manifest after execution. A developer who checked their node_modules folder an hour later might not have seen anything wrong.

Two characteristics make this incident particularly relevant for financial firms under DORA. First, the attack vector was the software supply chain, not the application itself. Second, the compromised package is not a niche tool. Axios is embedded in thousands of commercial software products, SaaS platforms, and internal applications across the financial sector. Most firms that use it have no idea they do.

Why DORA Third-Party Risk Management Cannot Ignore Open-Source Dependencies

DORA’s third-party risk framework, set out in Chapter V of Regulation (EU) 2022/2554, requires financial entities to identify, assess, and manage ICT third-party risk across the full lifecycle of their contractual arrangements. Article 28(3) requires entities to maintain a Register of Information covering all contractual arrangements on the use of ICT services provided by third-party service providers.

The problem: most registers stop at the vendor. They list the cloud provider, the core banking system vendor, the market data provider. They do not list Axios. They do not list the 47 other open-source packages embedded in the market data provider’s front-end application. And they certainly do not track which version of those packages is running in production.

This is not a minor gap. DORA Article 28(2) requires financial entities to keep the register “at entity level and at sub-consolidated and consolidated levels.” The ITS on the Register of Information (Commission Implementing Regulation (EU) 2024/2956) defines specific templates that include fields for the ICT service supply chain (template B_05.02). Template B_05.01 requires identification of ICT third-party service providers, and B_02.01 requires mapping contractual arrangements to the functions they support.

What teams commonly get wrong here: they treat subcontracting as a question about whether their vendor outsources hosting to AWS or data entry to an offshore centre. They do not treat embedded open-source software components as part of the ICT service supply chain. Regulators, however, are starting to think about it exactly that way.

Dependency Visibility: The Register Gap You Already Have

I have reviewed Register of Information submissions where firms diligently listed their top 30 ICT providers, mapped each to business functions, and documented data processing locations. Solid work. But the same firms had zero visibility into the software components those providers used to deliver their services.

An ICT third-party service provider that builds its platform on Axios is, in effect, relying on an open-source project maintained by a single individual. The Axios maintainer’s npm account was the single point of failure for this entire attack. No code review process, no release approval workflow, no separation of duties. One compromised credential, and 100 million weekly downloads became a malware distribution channel.

DORA does not require you to list every npm package in your register. That would be operationally absurd. But DORA Article 28(3) requires that the register document all contractual arrangements on the use of ICT services, enabling the monitoring of ICT third-party risk. And Article 30(2)(a) requires contractual provisions ensuring the financial entity can monitor the ICT third-party service provider’s performance “on an ongoing basis.” If your provider’s software supply chain is opaque to you, that monitoring obligation is hollow.

The practical question is not whether to add Axios to template B_05.01. The question is whether your contractual arrangements require your ICT providers to maintain a Software Bill of Materials (SBOM), to notify you of supply chain incidents affecting their products, and to demonstrate that they have controls over their own dependency management. If your contracts are silent on this, the Axios incident is your signal to fix that.

Subcontracting Chains: Where the Register of Information Gets Tested

The RTS on subcontracting (Commission Delegated Regulation (EU) 2025/532) requires financial entities to assess the risks arising from subcontracting arrangements, including the impact of a subcontractor’s failure on ICT services supporting critical or important functions. Article 3(1)(f) of that RTS specifically mentions considering “the impact of a possible failure of a subcontractor on the provision of ICT services.”

Open-source libraries are not subcontractors in the traditional sense. There is no contract with the Axios maintainer. No SLA. No right to audit. That distinction matters legally. But from an operational risk perspective, the dependency is real. If Axios breaks or gets compromised, and your vendor’s platform depends on it, the impact on your ICT services is identical to a subcontractor failure.

This creates a governance gap that most current registers do not address. The ICT service supply chain template (B_05.02 in the ITS) is designed for documented contractual relationships between your ICT provider and their subcontractors. It is not designed for transitive open-source dependencies. But the risk that template is meant to capture, the risk of cascading failure through layers of third-party reliance, is exactly what the Axios incident demonstrated.

What this means in practice: your register may be technically complete under the ITS templates, yet still fail to capture the operational risk that DORA Chapter V is built to address. That is a problem you need to solve through your broader ICT risk management framework, not just the register itself.

Worked Example: A Client Portal and Its Hidden Supply Chain

Consider a Luxembourg investment fund manager that contracts with Vendor A to provide and operate its client portal. Investors use this portal to view holdings, download statements, and submit redemption requests. The portal supports a critical function under the firm’s DORA classification.

Vendor A built the portal using a React front end that relies on Axios for every API call between the browser and the back end. Vendor A also uses a major cloud infrastructure provider (call it Cloud Co) for hosting and a third-party authentication service for investor login.

Here is where each piece lands in the register templates:

In B_05.01 (ICT third-party service providers), the firm documents Vendor A as the direct provider of the client portal ICT service. Cloud Co and the authentication service do not appear here because the firm has no direct contractual relationship with them.

In B_05.02 (ICT service supply chain), the firm documents the subcontracting chain under the contractual arrangement with Vendor A. Cloud Co appears as a first-tier subcontractor providing infrastructure. The authentication service appears as another first-tier subcontractor. For each, the firm records the service provided, the country of the subcontractor, and whether the subcontracted service supports the critical function.

In B_06.01 (functions identification), the firm maps the client portal to the critical function it supports: investor servicing and reporting.

In B_07.01 (assessments of ICT services supporting critical or important functions), the firm records its assessment of ICT concentration risk and substitutability for the Vendor A arrangement. This is where the dependency picture should get honest.

At sub-consolidated and consolidated levels, if applicable, these same templates aggregate information across entities in the group.

Now, where does Axios sit? Axios is not a subcontractor in the B_05.02 sense. There is no contract between Vendor A and the Axios maintainer. But Axios underpins every API call the portal makes. If the compromised version ran in Vendor A’s build pipeline, the portal itself becomes a vector for credential theft and data exfiltration.

Recital 7 of ITS 2024/2956 provides the materiality test here. It states that dependencies underpinning services could be of such significance that they should be “requalified as equivalent to an ICT service provided directly to the financial entity.” EBA Q&A 2024_7089 addresses a narrower point: that ICT subcontractors of non-ICT service providers remain outside the register scope. Axios does not meet that threshold in normal operation. But when a supply chain attack turns Axios into a backdoor that exfiltrates investor credentials from the client portal, the library is no longer a passive utility. It is the mechanism through which the critical function is compromised. That is the point at which the materiality argument tips.

The practical answer: you do not need to add Axios as a line item in B_05.02 under normal circumstances. But your ICT risk management framework should flag this class of dependency. When an incident like the March 2026 compromise occurs, your incident-driven reassessment should trace the impact through the supply chain, and the register’s additional information fields should capture what you found. If Vendor A cannot tell you whether Axios was in their build, that gap belongs in B_07.01 as a finding on your assessment of the arrangement.

The CSSF Supervisory Lens

Luxembourg firms operate under a supervisory layer that adds specificity to the DORA framework. Three CSSF circulars are directly relevant to how firms should be thinking about supply chain incidents like the Axios compromise.

Circular CSSF 25/882 sets out the CSSF’s practical instructions on DORA reporting obligations. It requires financial entities to notify the CSSF at least three months in advance of planned new ICT third-party arrangements supporting critical or important functions. It also defines the annual Register of Information submission window: 28 February to 31 March each year. The first collection cycle under this framework ended in March 2026. Firms that submitted their registers in that window did so before the Axios incident. The question for the next cycle is whether and how supply chain incidents from the intervening period are reflected in updated submissions.

Circular CSSF 25/883 amended the earlier Circular CSSF 22/806 on outsourcing arrangements. For DORA-scope entities, the amendment removes Part II of Circular 22/806 (which covered ICT outsourcing), since those requirements are now governed by DORA directly. Non-ICT outsourcing provisions under Part I remain applicable. This matters because many firms still operate under governance structures built around the pre-DORA outsourcing circular. Firms that have not yet updated their internal outsourcing policies and register processes to reflect this alignment are running on borrowed time.

The timing is significant. The first register collection cycle just closed. Supervisory attention will now shift to how firms handle changes between submissions. A supply chain incident affecting a library as widely used as Axios, followed by a CSSF communique treating it as a major ICT-related incident, is exactly the kind of event supervisors will expect firms to have captured in their ongoing risk management. Firms that treat the register as an annual filing exercise, disconnected from what happens between submission windows, will find that approach harder to defend.

Incident Classification: Mapping the Axios Compromise to DORA Reporting Triggers

The question of whether the Axios compromise qualifies as a major ICT-related incident under DORA has a clear answer. The CSSF communique of 3 April 2026 removed any ambiguity: the CSSF treated this as a major ICT-related incident and expected affected financial entities to report accordingly.

For firms that need to classify independently, Delegated Regulation (EU) 2024/1772 sets out the criteria. The Axios compromise maps to several specific triggers.

Clients, financial counterparts, and transactions affected: any financial entity whose systems ran the compromised Axios versions had its entire user base potentially exposed. The trojan enabled credential theft and arbitrary command execution, meaning client-facing systems processing transactions or holding personal data were at risk.

Data losses: the backdoor was designed for credential theft and data exfiltration. On compromised machines, the attacker had access to environment variables (which commonly store API keys, database credentials, and service tokens), file systems, and running processes. This is not a theoretical data loss scenario. The trojan actively enumerated and exfiltrated data.

Critical services affected: if the compromised library underpinned an ICT service supporting a critical or important function, that function was compromised. A client portal, a trading interface, or a payment processing system built on the poisoned version of Axios was running attacker-controlled code.

Duration: the malicious versions were live on npm for approximately three hours. But the incident timeline does not end at removal from npm. Any system that installed the compromised version during that window remains affected until the package is rolled back and all credentials, tokens, and keys accessible on the affected machine are rotated. For firms that do not have automated dependency monitoring, the actual exposure window may be days or weeks.

Notification follows three stages set out in the RTS on incident reporting (Commission Delegated Regulation (EU) 2025/301): an initial notification within 24 hours of classifying the incident as major, an intermediate report within 72 hours, and a final report within one month. Circular CSSF 25/893 implements this framework in Luxembourg. Firms that identified the compromised version in their environments on March 31 or April 1 should have filed their initial notification by April 2 at the latest.

Where firms get this wrong: they assume that because the malicious package was removed from npm quickly, the incident is contained. It is not. The containment question is whether the compromised version reached any of your environments or your providers’ environments, and whether all affected systems have been remediated. Until that is confirmed, the incident is open.

Materiality: When Does a Supply Chain Incident Reach Your Register?

Not every software vulnerability requires a register update. The question is materiality. DORA does not define a bright-line materiality threshold for register updates, but several factors from the regulation and its technical standards provide guidance.

Consider whether the affected component supports an ICT service underpinning a critical or important function. If yes, the incident is material for your register. Consider whether the compromise could have resulted in data exfiltration, credential theft, or unauthorized access to systems processing client data or transaction data. The Axios attack did all three.

Recital 7 of ITS 2024/2956 provides the anchoring principle here. It recognises that certain dependencies underpin services to such an extent that they could be “requalified as equivalent to an ICT service provided directly to the financial entity.” This is the test firms should apply to open-source dependencies. (EBA Q&A 2024_7089 addresses a related but narrower question: whether ICT subcontractors of non-ICT service providers fall within register scope. The answer is generally no, unless the dependency crosses the materiality threshold in Recital 7.) Under normal operating conditions, a utility library like Axios is a passive component. But when that library is compromised and becomes the active mechanism through which critical services are attacked, it crosses the materiality threshold. The Axios incident is the clearest real-world illustration of that transition.

Consider also Delegated Regulation (EU) 2024/1772. Article 7 lists “economic impact” criteria including expropriated funds, costs and losses from data theft, and costs of replacing compromised systems. A supply chain attack that deploys a remote access trojan across your build infrastructure meets several of those criteria.

The real trap is the reverse assumption: that because the malicious versions were live for only three hours, the impact must have been limited. Automated CI/CD pipelines can pull and install a compromised package within minutes of its publication. Three hours is a long time in that context. If your ICT provider uses automated deployments, the window of exposure matters less than whether the compromised version reached any environment at all.

Concentration Risk: One Package, Thousands of Providers

DORA Article 29 requires financial entities to conduct a preliminary assessment of ICT concentration risk at the entity level. The standard approach looks at how many critical functions depend on the same ICT provider. If your cloud hosting, email, and core processing all run on the same hyperscaler, that is concentration risk.

The Axios incident reveals a different kind of concentration. Not at the provider level, but at the component level. Axios sits inside products from dozens of vendors that financial firms use simultaneously. A single compromise of this one library could, in theory, affect your trading platform, your compliance tool, your client portal, and your internal communication system all at once. Not because they share a vendor, but because they share a dependency.

The systemic relevance here is comparable to a critical cloud provider, not because Axios is a provider in the DORA sense, but because its compromise affects virtually every financial institution simultaneously. When a hyperscaler has an outage, regulators and firms understand the concentration dynamic immediately. When a foundational open-source library is compromised, the same dynamic applies, but it is invisible to most risk frameworks.

This is a genuine blind spot. The ESAs’ oversight framework under DORA Articles 31-44 was designed for critical ICT third-party service providers: large cloud platforms, core banking system vendors, major data providers. The framework does not cover open-source projects or individual maintainers. There is no mechanism to designate an npm package as a “critical ICT third-party service provider” subject to Lead Overseer scrutiny. The maintainer of a library used by every bank in Europe has no reporting obligations, no governance requirements, and no regulatory relationship with financial supervisors.

Most concentration risk assessments do not capture this. They look at provider names, not at the shared technical components underneath. The ESAs’ consultation responses on the RTS on subcontracting acknowledged that monitoring “the entire chain of ICT subcontractors” is operationally challenging, and several respondents flagged concerns about proportionality. But the risk is real regardless of whether the templates make it easy to document.

The recommendation: add widely used open-source components to your Article 29 concentration risk assessment even if they do not fit neatly into the register templates. You will not find a field in B_07.01 for “npm packages used by multiple providers.” But your concentration risk narrative should identify this class of dependency and explain how you monitor and mitigate it. If your risk committee has never discussed what happens when a foundational library is compromised across your entire vendor ecosystem, the Axios incident is the concrete example to bring to the table.

Incident-Driven Reassessment: When Your Register Needs Updating

The Register of Information is not a file-and-forget document. DORA Article 28(3) requires financial entities to report at least annually to competent authorities on the number of new arrangements, the categories of ICT third-party service providers, and the type of contractual arrangements. But the register should also reflect material changes in risk between reporting periods.

A supply chain attack affecting a component used by one of your ICT providers is exactly the kind of event that should trigger a reassessment. Not a full rewrite of the register. A targeted review: which providers use the affected component? Do any of them support critical or important functions? Did they confirm remediation?

The Axios compromise is a useful test case for your incident-driven update process. If your firm has no process for updating the Register of Information when a third-party supply chain incident occurs, now is the time to build one. Circular CSSF 25/882 reinforces the expectation that financial entities maintain their registers in a way that is “complete, accurate, and up to date.” With the first annual submission window just closed, the CSSF will be watching how firms handle incidents that emerge between cycles.

Where teams get this wrong: they treat the register as a compliance filing due on a fixed schedule, disconnected from their operational risk processes. The incident response team learns about the Axios compromise on day one. The compliance team updating the register hears about it three months later, if at all. That disconnect is exactly what DORA is designed to eliminate.

What to Review and Update Now

In Your Register of Information

Start with template B_02.01 (contractual arrangements). For every ICT provider that supports a critical or important function, check whether the contract includes obligations to notify you of supply chain security incidents affecting their products. If it does not, flag the gap. You cannot update the supply chain template if you have no contractual right to the information.

Then review template B_05.01 (ICT third-party service providers). For providers using web technologies, JavaScript frameworks, or cloud-native architectures, ask whether they were affected by the Axios compromise. Their answer tells you two things: whether there is an immediate remediation need, and whether they have the supply chain visibility to answer the question at all. If they cannot tell you whether they use Axios, that is a finding worth documenting.

For providers that confirm Axios is in their stack, check whether their subcontracting information in B_05.02 needs updating. The supply chain template captures the chain of ICT subcontractors. While Axios itself may not warrant a line item under normal conditions (per the Recital 7 materiality test in ITS 2024/2956), a confirmed compromise affecting the provider’s service delivery to your firm does warrant documentation in the additional information fields.

Finally, consider whether your register captures enough context about how ICT services are delivered, not just who delivers them. The ITS templates have fields for “nature of ICT services” and data processing locations. They do not have a field for “key open-source dependencies.” But the “additional information” fields exist for exactly this purpose. Use them.

In Your Governance and Contracts

Review your standard ICT outsourcing contract clauses. DORA Article 30(3)(e) requires provisions that ensure the ICT third-party service provider will assist the financial entity when ICT incidents occur. Extend this to supply chain incidents. Your contracts should require providers to:

Maintain and share a Software Bill of Materials for the components of their product that process your data or support your functions. Notify you within a defined timeframe when a supply chain compromise affects their product. Confirm remediation steps and timelines.

Also review your ICT risk assessment methodology. If it currently assesses third-party risk only at the vendor level, expand it to include a component-level view for critical functions. You do not need to audit every library. But you need to know whether your critical providers have controls over their own software supply chains.

In Your Incident Response Process

Build a link between your ICT incident monitoring process and your Register of Information update process. When your security operations team or threat intelligence function identifies a supply chain incident affecting a widely used software component, the process should include a step to check whether any registered ICT providers are affected.

This does not need to be complex. A simple triage question: “Does this incident affect any component used by a provider in our register?” If yes, escalate to the team responsible for the register. If the answer is “we don’t know,” that tells you where your visibility gap is.

Practical Actions by Team

ICT Security Teams

Run a dependency audit across your own systems. If your firm develops or maintains internal applications, check whether Axios versions 1.14.1 or 0.30.4 were installed in any environment. Roll back to 1.14.0 or 0.30.3. Rotate any credentials or API keys that may have been exposed on affected machines. Microsoft and Google both published detailed indicators of compromise.

Beyond the immediate incident: implement lockfile enforcement in your CI/CD pipelines. Pin dependency versions. Disable automatic postinstall script execution for untrusted packages. These are the controls that would have blocked the Axios attack entirely.

Compliance and Risk Teams

Use this incident as a test of your third-party risk monitoring process. Ask your top 10 ICT providers (by criticality) whether they were affected. Document the responses. For providers that cannot answer, or that answer after an unreasonable delay, flag this as a gap in your ongoing monitoring under DORA Article 28.

Review whether your current ICT risk assessment methodology accounts for transitive dependency risk. If it treats third-party risk as purely a question of the bilateral provider relationship, it is missing a category of risk that the Axios incident puts in sharp focus.

Procurement and Legal Teams

Start adding software supply chain clauses to new ICT contracts and renewals. SBOM requirements, supply chain incident notification, and the right to receive information about key dependencies are becoming standard in sectors with mature supply chain governance. Financial services is catching up.

For existing contracts supporting critical or important functions, check whether the current provisions in Article 30(2) and 30(3) of DORA are reflected. If your contracts predate DORA’s application date of January 17, 2025, they likely need updating. The Axios incident gives you a concrete business case for prioritising those renegotiations.

Exit Strategy: Can You Walk Away from Axios?

DORA Article 28(8) requires financial entities to ensure they can exit ICT third-party arrangements without disruption to business activities and without limiting compliance with regulatory requirements. In the Axios context, this translates into a specific question: if Axios is compromised again, or if the project is abandoned, can your applications and your vendors’ systems continue to operate?

For internal applications, this means verifying that an alternative HTTP client library (such as the native Fetch API, ky, or got) can replace Axios without breaking functionality. If your codebase has Axios calls in 200 files, that migration is not trivial, and you should know the effort estimate before a crisis forces it.

For vendor-provided systems, the exit strategy question shifts. You cannot control which HTTP library your vendor uses. But you can require, through your contractual provisions, that the vendor has its own exit strategy for critical dependencies. You can also verify that your firm can rapidly pin vendor packages to a known-safe version when a compromise is discovered, rather than waiting for the vendor to push a fix.

Where teams get this wrong: they think of exit strategy only in terms of switching vendors. DORA Article 28(8) is broader. It applies to the ability to exit any ICT third-party arrangement. When a dependency like Axios becomes a risk vector, the relevant exit question is whether you can isolate or replace the compromised component without taking critical systems offline.

Non-DORA Entities: Circular CSSF 24/847 Still Applies

Not every financial entity in Luxembourg falls under DORA’s ICT third-party risk framework. Entities outside DORA’s scope, including certain smaller investment funds, non-regulated holding companies, and support PSFs not providing ICT services, may still be subject to the CSSF’s general outsourcing and ICT risk expectations. Circular CSSF 24/847, which consolidated the CSSF’s technology risk requirements for entities not in DORA’s scope, remains the reference framework for those firms.

The Axios incident does not create DORA obligations for non-DORA entities. But it does raise the same operational questions about vendor dependency visibility, incident response, and supply chain risk. Firms operating under Circular CSSF 24/847 should treat this incident as a prompt to review their own ICT risk management practices, even if they are not required to maintain a formal Register of Information.

After Axios: What Your Register Should Actually Reflect

The Axios supply chain attack is not an outlier. Palo Alto Networks’ Unit 42 noted that attackers have been increasing the frequency and scale of npm supply chain operations since early 2026. The Trivy compromise in March 2026 followed a similar pattern. These incidents are becoming routine.

DORA’s Register of Information was designed to give competent authorities and firms themselves a structured view of ICT third-party dependencies. That view is incomplete if it stops at the contractual layer and ignores the technical supply chain underneath. The ITS templates may not have a dedicated field for “open-source component risk,” but the regulation’s intent is clear: know what you depend on, monitor it, and be able to respond when something goes wrong.

After the Axios incident, the minimum defensible position for a regulated financial entity is this: you know which of your critical ICT providers were or were not affected, you have a process to find out next time, your contracts give you the right to that information, and your register reflects what you learned. Everything else is refinement. Start there.

Frequently Asked Questions

Does the Axios NPM package count as an ICT third-party service provider under DORA?

Strictly, no. DORA Article 2(1) defines ICT third-party service providers as undertakings providing ICT services. An open-source library distributed through npm is not an undertaking, and there is no contractual arrangement. However, DORA’s risk management requirements in Articles 28 and 29 look at the substance of ICT dependencies, not just their legal form. The vendor that uses Axios in its product is your ICT third-party service provider, and Axios is part of that provider’s ICT service supply chain. Your risk management framework should capture the dependency even if the register templates do not have a dedicated field for it.

Do I need to list every NPM package in my Register of Information?

No. That would be operationally absurd and is not what the ITS requires. The register documents ICT third-party service providers and their subcontracting chains. Embedded open-source libraries are not subcontractors. What you do need is visibility into which of your providers use widely deployed, potentially high-risk components, and contractual provisions requiring providers to notify you of supply chain incidents. Your Article 29 concentration risk assessment should identify classes of shared components, not individual package names.

Is this incident reportable if we were not directly affected?

If your internal systems did not install the compromised Axios versions and none of your ICT providers confirmed exposure, you are unlikely to have a reporting obligation under DORA’s incident reporting framework. However, you should still document the assessment. The fact that you checked, contacted providers, and confirmed no impact is itself a defensible record of your ongoing monitoring under Article 28. If a provider later discovers they were affected, the reporting clock starts from the point you classify the incident as major.

Our vendor says they were not affected. Do we need to verify independently?

DORA Article 30(2)(a) requires contractual provisions for ongoing monitoring of ICT third-party service provider performance. A vendor’s self-assessment is a starting point, not the end of your obligation. For providers supporting critical or important functions, you should ask for specifics: did they use Axios? Which version? Did their CI/CD pipeline pull packages during the three-hour window? Can they provide evidence from their dependency management tools? A vague “we were not affected” without supporting detail is a finding, not an assurance.

How does this relate to DORA’s oversight framework for critical third-party providers?

DORA Articles 31-44 establish a direct oversight framework for ICT third-party service providers designated as critical by the ESAs. This framework gives Lead Overseers powers to inspect, request information, and issue recommendations to critical providers. It does not apply to open-source projects or individual maintainers. There is no mechanism under DORA to designate an npm package or its maintainer as a critical ICT third-party service provider. This is a structural gap in the oversight framework. Firms should not wait for the oversight framework to cover open-source risk. They should address it through their own ICT risk management and contractual arrangements under Articles 28-30.

Related Articles

DORA Register of Information: What Luxembourg Firms Need to Know – Comprehensive guide to the Register of Information templates, submission process, and CSSF expectations.

DORA ICT Incident Reporting: A Practical Guide for Luxembourg Financial Entities – Covers the three-stage incident notification process, classification criteria, and CSSF-specific requirements.

PSD2 Reporting Requirements – For payment institutions and e-money institutions that may face overlapping ICT risk and operational resilience requirements.

DORA Compliance Checklist for Luxembourg Fund Administrators – Practical checklist covering ICT risk management, third-party risk, and incident reporting for fund administrators.

Sources and References

Regulation (EU) 2022/2554 (DORA), Articles 28, 29, 30, 31-44: EUR-Lex

Commission Implementing Regulation (EU) 2024/2956, ITS on the Register of Information: EUR-Lex

Commission Delegated Regulation (EU) 2025/532 of 24 March 2025, RTS on subcontracting: EUR-Lex

Commission Delegated Regulation (EU) 2024/1772, RTS on classification of major ICT incidents: EUR-Lex

Commission Delegated Regulation (EU) 2025/301, RTS on incident reporting: EUR-Lex

EBA Q&A 2024_7089 on documentation of ICT subcontractors in the Register of Information: EBA Single Rulebook Q&A

CSSF Circular 25/882, requirements on the use of ICT third-party services under DORA: CSSF

CSSF Circular 25/883, amendment of CSSF 22/806 on outsourcing arrangements (carving out ICT outsourcing for DORA-scope entities): CSSF

CSSF Circular 25/893, ICT-related incident reporting under DORA: CSSF

CSSF Circular 24/847, technology risk requirements for non-DORA entities: CSSF

CSSF Communique of 3 April 2026 on the Axios NPM supply chain incident: CSSF

Google Threat Intelligence Group, “North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack,” April 2026: Google Cloud Blog

Microsoft Security Blog, “Mitigating the Axios npm supply chain compromise,” April 2026: Microsoft

Snyk, “Axios npm Package Compromised: Supply Chain Attack Delivers Cross-Platform RAT,” March 2026: Snyk Blog

Palo Alto Networks Unit 42, “Threat Brief: Widespread Impact of the Axios Supply Chain Attack,” April 2026: Unit 42

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.