Financial regulators no longer accept "we trust our vendors" as a supply chain security strategy. Since January 17, 2025, the EU's Digital Operational Resilience Act (DORA) has applied to roughly 22,000 financial entities and their ICT providers — banks, insurers, payment firms, crypto-asset service providers, and the trading platforms and cloud vendors they depend on. Buried inside DORA's ICT risk management obligations is a requirement that security and compliance teams are still scrambling to operationalize: knowing exactly what software components run inside every system that touches critical or important functions. That's where DORA SBOM requirements come in. A software bill of materials — a structured inventory of every open-source library, dependency, and third-party component in an application — has moved from a nice-to-have engineering artifact to a regulatory expectation. This post breaks down what DORA actually requires, who it applies to, and how to build a program that satisfies examiners without slowing down engineering.
What Are the DORA SBOM Requirements for Financial Entities?
DORA does not use the word "SBOM" anywhere in its text, but its ICT risk management SBOM obligations are unmistakable once you read Articles 8 and 9 alongside the Regulatory Technical Standards (RTS) on ICT risk management. Article 8 requires financial entities to maintain an "updated inventory of ICT assets," including a clear identification of "which ones support critical or important functions." Article 9 goes further, requiring entities to identify and document "all sources of ICT risk," including vulnerabilities in software components. The RTS on ICT risk management, finalized by the European Supervisory Authorities in 2024, gets specific: entities must maintain records of software and hardware assets down to the component level, track version and patch status, and map dependencies between systems. In practice, the only scalable way to meet that bar — across potentially thousands of applications and third-party services — is an automated, continuously updated SBOM pipeline, not a spreadsheet updated during audit season.
Which Financial Entities Actually Have to Comply?
Nearly every regulated financial entity operating in the EU is in scope, and so is a meaningful slice of the software vendors that sell to them. DORA's Article 2 lists 21 categories of financial entities — credit institutions, payment institutions, e-money firms, investment firms, insurance and reinsurance undertakings, crowdfunding platforms, crypto-asset service providers under MiCA, and trading venues, among others. Proportionality applies: a five-person payment institution isn't held to the same documentation depth as a global systemically important bank, but the underlying obligation to maintain an ICT asset inventory and manage third-party risk applies regardless of size. Critically, DORA also reaches upstream. Article 28 requires financial entities to maintain a full "register of information" covering every ICT third-party provider, and if a provider is later designated "critical" under the DORA oversight framework (the first batch of critical ICT third-party providers was designated by the European Supervisory Authorities in 2025), that vendor is subject to direct oversight, examination, and potential penalties of up to 1% of average daily worldwide turnover for continued non-compliance. If you sell software to a bank, insurer, or payment processor in the EU, your SBOM practices are now effectively part of your customer's compliance posture.
How Does DORA Treat ICT Third-Party and Software Supply Chain Risk?
DORA treats third-party and supply chain risk as inseparable from an entity's own operational resilience — a vendor's vulnerability is legally the bank's problem. This is the core shift behind Digital Operational Resilience Act ICT third-party risk provisions: Chapter V requires financial entities to assess concentration risk, maintain exit strategies for critical providers, and — under Article 30 — include specific contractual clauses obligating ICT providers to cooperate on incident reporting, audits, and vulnerability disclosure. The EU DORA software supply chain angle became impossible to ignore after incidents like the 2020 SolarWinds compromise and the 2021 Log4Shell vulnerability, both cited repeatedly in DORA's recitals and in ESA guidance as the type of cascading, multi-entity failure the regulation is designed to prevent. When a component like Log4j turns out to be embedded four layers deep in a vendor's platform, an SBOM is the only artifact that lets a financial entity answer "are we exposed?" in hours instead of weeks. Regulators have made clear they expect that answer to be fast.
What Format and Level of Detail Does an SBOM Need for DORA?
DORA does not mandate a specific SBOM file format, but the RTS's requirements for component-level tracking, dependency mapping, and vulnerability correlation point strongly toward the two industry-standard machine-readable formats: CycloneDX and SPDX. A PDF list of libraries or a static vendor questionnaire won't satisfy the "updated inventory" language in Article 8 — updated implies continuous, and continuous implies automated generation from your actual build pipeline, not a manual export done once a year. At minimum, an SBOM built for DORA compliance needs to capture: component name and version, license, direct and transitive dependencies, known vulnerability identifiers (CVEs), and a timestamp tied to the build or release it describes. Entities managing multiple business lines typically need SBOMs generated at every release for systems supporting critical or important functions, stored in a format that can be handed to a supervisory authority on request and cross-referenced automatically against new CVE disclosures — not regenerated retroactively when an examiner asks.
What Happens If a Financial Entity Can't Produce an SBOM During an Audit?
Gaps in ICT asset inventories are already showing up as audit findings, and under DORA they carry real financial and operational consequences, not just a strongly worded letter. National competent authorities (NCAs) — for example BaFin in Germany, the ACPR in France, or the Central Bank of Ireland — have supervisory and enforcement powers under DORA that include the ability to impose administrative penalties, require remediation plans with deadlines, and in serious cases restrict an entity's ability to operate specific ICT systems until gaps are closed. Beyond direct penalties, an incomplete component inventory undermines two other DORA obligations simultaneously: the 24-hour/72-hour major-incident-reporting timelines in Article 19 (you can't scope an incident's blast radius if you don't know what's running) and the threat-led penetration testing (TLPT) requirements in Chapter IV, which assume testers already understand the target's technical composition. Financial entities that treated SBOM generation as a compliance checkbox rather than a live operational capability are the ones most likely to fail an incident-response drill or a supervisory review in 2026 as enforcement matures past its first-year grace period.
How Safeguard Helps
Safeguard was built to turn DORA's ICT risk management SBOM language into a running system, not a once-a-year audit scramble. We generate CycloneDX and SPDX-compliant SBOMs automatically at every build, across every repository and service supporting critical or important functions, so the "updated inventory" requirement in Article 8 is satisfied continuously rather than reconstructed under deadline pressure. Safeguard continuously correlates every component in your inventory against newly disclosed CVEs and maps transitive dependencies so a Log4Shell-style disclosure produces an answer in minutes, not a multi-week fire drill — directly supporting the incident classification and reporting timelines in Article 19. For the third-party side of the equation, Safeguard helps you build and maintain the register of information required under Article 28 by ingesting SBOMs and attestations from your ICT providers, flagging vendors with weak provenance or unpatched critical vulnerabilities before they become part of a supervisory finding. And because every SBOM is versioned, timestamped, and exportable on demand, your compliance and audit teams can hand a regulator exactly what Article 9 and the RTS require without engineering having to stop and manually assemble it. If your organization is still treating DORA SBOM requirements as a documentation exercise, that's the gap Safeguard closes — turning supply chain visibility into a standing capability instead of a periodic project.