Supplier Software Risk Under DORA, NIS2 and M-26-05, With Safeguard TPRM

DORA, NIS2 and US federal software policy all ask the same thing of a buyer: know which suppliers your critical services depend on, judge their software on evidence, and keep judging it after the contract is signed. Safeguard TPRM (GA) is built for the evidence half of that job. It keeps a vendor directory with risk tiers, sends and tracks SBOM requests, scores each vendor from 0 to 100 using vulnerability, compliance, component and operational factors with EPSS and CISA KEV, and re-scans vendor SBOMs as new CVEs land.

It does not replace your contracts, your register of information or your audit rights. It gives those documents something current to point at.

One thing to know before you read on: OMB M-22-18, the US memo in this post's title, was rescinded on 23 January 2026 by OMB M-26-05. We explain below what changed, what survived, and why the SBOM request workflow matters more under the new memo, not less.

Key takeaways

• DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025) makes financial entities fully responsible for ICT third-party risk (Article 28(1)(a)), requires a register of information on all ICT contracts (Article 28(3)), concentration risk checks (Article 29) and minimum contract terms including audit and monitoring rights (Article 30).
• NIS2 (Directive (EU) 2022/2555) lists supply chain security as a mandatory measure in Article 21(2)(d) and, in Article 21(3), tells entities to weigh each direct supplier's vulnerabilities and secure development procedures.
• US federal policy moved from M-22-18's mandatory attestations to M-26-05's risk-based approach. Agencies may still require a current SBOM upon request by contract. NIST SP 800-161 Rev. 1 remains the reference for cybersecurity supply chain risk management.
• Safeguard TPRM (GA) covers vendor management and risk tiers, single and bulk SBOM requests tracked through Sent, Viewed, In Progress, Submitted, Validated or Rejected, a 0 to 100 vendor risk score where higher is better, and continuous monitoring with alerts to email, Slack, Microsoft Teams, PagerDuty or a webhook.
• Supporting capabilities used here: SBOM generation and analysis (GA), vulnerability management with EPSS and KEV (GA), the compliance and GRC suite with its Vendors and Questionnaires areas (GA), Portal as the SBOM storage and sharing surface (GA), the Safeguard CLI and MCP server (GA), the mobile app (early access, beta) and Trust Center (early access).
• Limits: a score is only as good as what vendors submit; a vendor can refuse to send an SBOM; TPRM cannot verify code it never saw; and it does not replace contractual rights or the regulatory register.

The problem: supplier software you cannot see into

Most organisations run more software they bought than software they wrote, and each of those products carries its own open source dependencies. When a widely used library gets a critical CVE, the question a regulator or board asks is "which of your suppliers ship that library, in which products, and what did they tell you?"

Without a working process, the answer is a spreadsheet of vendor names and an annual questionnaire that says nothing about which library versions are inside last month's build. When the CVE drops, someone emails forty account managers and waits.

Current regulations target exactly that gap. None says "SBOM required for every supplier", but all push buyers toward evidence that is specific, current and reviewable.

What goes wrong without evidence

Questionnaire-only programmes fail in predictable ways. Answers go stale as the product ships new releases. Nobody can match a new CVE to a vendor that was never known to ship the component. Every vendor gets the same form, so critical suppliers are reviewed no more deeply than trivial ones. Promised fixes are never tracked. And when the competent authority asks how a critical provider is monitored, the evidence is scattered across mailboxes.

What the regulations require for supplier software

We quote article and clause numbers from the primary texts.

DORA Articles 28 to 30 and the register of information

DORA, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, applies from 17 January 2025. Its Chapter V, Section I sets out "key principles for a sound management of ICT third-party risk". Three articles matter most for supplier software.

Article 28, general principles. Article 28(1)(a) says a financial entity that uses ICT services from third parties remains "fully responsible" for its obligations. Outsourcing the software does not outsource the accountability. Article 28(1)(b) applies proportionality, taking into account the nature, scale, complexity and importance of ICT dependencies and the criticality of each service.

Article 28(2) requires most financial entities to adopt and regularly review a strategy on ICT third-party risk, including a policy on ICT services supporting critical or important functions.

Article 28(3) is the register of information. Financial entities must "maintain and update" a register covering all contractual arrangements on the use of ICT services, at entity, sub-consolidated and consolidated levels. The register must distinguish arrangements that support critical or important functions, the entity must report at least yearly on new arrangements, and it must hand over the full register or specified sections when the competent authority asks.

Article 28(4) lists what must happen before signing, including assessing all relevant risks (concentration risk among them) and to "undertake all due diligence" on the prospective provider. Article 28(5) limits contracts to providers that meet appropriate information security standards, Article 28(6) requires a risk based audit plan, Article 28(7) lists termination grounds including weaknesses found through monitoring, and Article 28(8) requires exit strategies for critical or important functions.

Article 29, concentration risk. Before contracting for services that support critical or important functions, the entity must consider whether the provider is easily substitutable, and whether it already has multiple arrangements with the same or "closely connected" providers. Article 29(2) adds subcontracting: entities must assess whether long or complex subcontracting chains affect their ability to monitor the contracted functions.

Article 30, key contractual provisions. Article 30(2) sets minimum terms for every ICT contract, including a full description of services, data locations, data protection provisions, incident assistance and termination rights. Article 30(3) adds terms for services supporting critical or important functions, including notice and reporting obligations on the provider and, in point (e), "the right to monitor, on an ongoing basis" the provider's performance, with unrestricted rights of access, inspection and audit.

DORA's definition of "ICT services" in Article 3 covers "digital and data services provided through ICT systems" on an ongoing basis, so licensed software, SaaS and managed services all sit inside it.

The register of information templates. Article 28(9) asked the European Supervisory Authorities to draft standard templates. The result is Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024. Its Article 3(4) requires the register to meet data quality principles of accuracy, completeness, consistency, integrity, uniformity and validity. Article 3(5) requires a valid LEI or EUID for each provider that is a legal person. Article 2 introduces a "rank" for each provider in the ICT service supply chain, with the direct provider always ranked 1 and subcontractors ranked higher.

Two templates are worth knowing by code. Template B_05.02 maps the ICT service supply chain, linking direct providers and their subcontractors. Template B_07.01 records the assessment of ICT services that support critical or important functions, with columns such as substitutability (B_07.01.0050), the date of the last audit on the provider (B_07.01.0070), the existence of an exit plan (B_07.01.0080) and the impact of discontinuing the service (B_07.01.0100).

The EBA's DORA preparation page confirms that from 17 January 2025 every financial entity in scope needs this register available at all levels, and it publishes the reporting taxonomy, validation rules and FAQs.

DORA never says "collect an SBOM". It says due diligence, ongoing monitoring, audit rights and an accurate register. Component level evidence is a practical way to make "ongoing monitoring" mean something for software.

NIS2 Article 21(2)(d) and the supply chain measures

NIS2, Directive (EU) 2022/2555, required Member States to adopt their transposition measures by 17 October 2024 and apply them from 18 October 2024 (Article 41). Article 21(1) requires essential and important entities to take "appropriate and proportionate" measures to manage risks to their network and information systems. Article 21(2) lists the minimum set, and point (d) is "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers".

Article 21(3) is the part most teams miss. When choosing supply chain measures, entities must "take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures." That is a per supplier, per product judgement, not a blanket policy.

Recital 85 explains why: incidents where attackers compromised an entity "by exploiting vulnerabilities affecting third-party products and services", with software editors named among the supplier types that matter.

For a specific group of digital providers (DNS, TLD registries, cloud, data centres, CDNs, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers), Commission Implementing Regulation (EU) 2024/2690 spells out the technical requirements. Section 5 of its Annex covers supply chain security:

• 5.1.1 requires a supply chain security policy governing relations with direct suppliers and service providers.
• 5.1.2 requires selection criteria including the supplier's cybersecurity practices and secure development procedures, and "the overall quality and resilience of ICT products and ICT services".
• 5.1.4 lists contract terms where appropriate, including the right to audit or to receive audit reports, a supplier obligation to notify incidents, and an obligation on suppliers "to handle vulnerabilities" that present a risk.
• 5.1.6 and 5.1.7 require monitoring and review of suppliers at planned intervals and after significant changes or incidents, including reviewing incidents related to supplier products and analysing the risk of changes to those products.
• 5.2 requires a registry of direct suppliers with contact points and a list of the ICT products, services and processes each provides.

Even outside those provider types, 2024/2690 is a useful reading of what Article 21(2)(d) looks like in practice.

NIST SP 800-161 Rev. 1

NIST SP 800-161 Rev. 1, "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations", was published in May 2022 and includes updates as of 1 November 2024. It is the main US reference for cybersecurity supply chain risk management (C-SCRM) and is written for any organisation, not only federal agencies.

Two of its control supplements map directly to supplier software:

• SR-4, Provenance. The supplemental guidance says enterprises "should consider producing SBOMs for applicable and appropriate classes of software, including purchased software". It also warns against treating SBOMs as a replacement for vendor risk assessments: they are "a complementary, not substitutive, capability", and organisations that cannot ingest, analyse and act on SBOM data are unlikely to improve their posture.
• SR-6, Supplier assessments and reviews. The guidance asks enterprises to apply supplier information "against a consistent set of core baseline factors and assessment criteria" so suppliers can be compared fairly with each other and over time, and to consider the quality of the information relied on.

CM-8(10) adds a practical note for open source with no SBOM: contribute SBOM generation upstream, fund it, or generate one yourself on first consumption of each version.

These three ideas (consistent criteria, evidence quality, and SBOMs as one input among several) are a good test for any tool that claims to score vendors.

OMB M-22-18, its rescission, and OMB M-26-05

OMB M-22-18, dated 14 September 2022, told federal agencies to obtain a self-attestation from software producers before using their software, following the NIST guidance issued under EO 14028. Where a producer could not attest to a practice, the agency had to require a Plan of Action and Milestones. The memo let agencies require an SBOM in solicitations based on the software's criticality, said SBOMs must use one of the formats in the NTIA minimum elements report, and allowed agencies to ask for other artifacts, such as results from tools that "check for known or potential vulnerabilities", and evidence of a vulnerability disclosure programme. M-23-16 later updated its timelines.

On 23 January 2026, OMB M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security", rescinded both M-22-18 and M-23-16. The new memo says each agency head is responsible for assuring the security of software and hardware on the agency's network and should validate provider security "based on a comprehensive risk assessment". It keeps three things that matter here:

1. Agencies "shall continue to maintain a complete inventory of software and hardware".
2. Agencies may still use the Secure Software Development Attestation Form and other resources built under M-22-18.
3. Agencies may adopt contract terms that require a producer to provide a current SBOM upon request. For a cloud platform, the footnote says the SBOM should cover the runtime production environment.

M-26-05 also points agencies to NIST SP 800-218 (the SSDF) and to CISA's SBOM minimum elements guidance. Since then, CISA, NSA, the FBI and international partners published the 2026 Minimum Elements for an SBOM on 29 July 2026, which updates and replaces the NTIA 2021 minimum elements.

So the federal posture has moved from "collect a standard form from everyone" to "decide by risk, and be able to get an SBOM on request". For a supplier risk team, that makes the ability to request, validate and re-check SBOMs per vendor and per tier more useful, because the burden of deciding who needs one now sits with the buyer.

Other references worth knowing

• ENISA, Good Practices for Supply Chain Cybersecurity (13 June 2023) reviews how EU essential and important entities approach supply chain cybersecurity, based on a 2022 ENISA study.
• CISA KEV is, in CISA's words, "the authoritative source of vulnerabilities that have been exploited in the wild", and CISA recommends it as an input to prioritisation.
• FIRST EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days and publishes a score for every CVE daily.

Requirement map: what each rule asks, what Safeguard does, what you still own

How Safeguard TPRM handles supplier software risk

TPRM is one of Safeguard's four products, alongside the Enterprise Software Supply Chain Manager (ESSCM), Portal and the Open Source Manager. Safeguard's offering describes it as the place to onboard vendors, request SBOMs, projects or products from them, score and continuously monitor supplier risk, and apply policies and gates. The docs split it into four modules: Vendor Management, SBOM Requests, Risk Assessment and Monitoring.

The getting started sequence in the docs is short: add vendors to your directory, categorise them by risk tier, request SBOMs from high risk vendors, review and validate submissions, and enable continuous monitoring. The sections below follow that order.

How do you onboard a vendor and set a risk tier in Safeguard TPRM?

Safeguard's Vendor Management docs describe the flow like this.

1. Navigate to Vendors.
2. Click Add Vendor.
3. Enter the vendor information: company name, primary contact, contact email, website and the products you use.
4. Set the risk tier.
5. Click Save.

For a large estate, use Bulk Import: download the template CSV, fill in the vendor information, upload the completed file, then review and confirm the import. Import from the same master list as your DORA register so both use the same vendor names.

Each vendor record tracks the company name, the products you use, the primary contact, contract status (active, pending or expired), risk tier, SBOM status (received, requested or none) and the date of the last assessment.

Risk tiers. TPRM uses four tiers, and the docs attach an SBOM expectation to each:

TPRM can suggest a tier based on data access level, system criticality, user count and compliance requirements. You can override it: select the vendor, click Edit Risk Tier, choose the new tier, document the justification and save. That justification field is worth using every time. Under DORA, the line between "supports a critical or important function" and "does not" is a regulated judgement, and a supervisor will want to see why a vendor sits where it does.

A sensible mapping for a financial entity is to treat every ICT service that supports a critical or important function as Critical or High in TPRM, so that the SBOM requirement and monitoring cadence follow the DORA classification automatically.

Vendor relationships and contracts. The docs let you record relationships between vendors (parent companies, subsidiaries, resellers and implementation partners) and link contracts to vendors, with contract documents, start and end dates, SLA terms, security requirements and SBOM obligations. Relationships help with the "closely connected providers" question in DORA Article 29(1)(b). Contracts give you a place to record whether the SBOM obligation you are about to enforce actually exists in writing.

Vendor portal. You can invite vendors to a self service portal where they update their own information, submit SBOMs directly, respond to questionnaires and view their risk status.

Step by step: send an SBOM request and track it to Validated or Rejected

This is the heart of an evidence based programme. Safeguard's SBOM Requests docs describe two ways to send requests.

A single request (for example, pre-contract due diligence on one new supplier):

1. Navigate to the vendor.
2. Click Request SBOM.
3. Select the product or products.
4. Choose a request template.
5. Customise the message (optional).
6. Set a deadline.
7. Click Send.

A bulk request (for example, the annual refresh for every High tier vendor):

1. Go to Vendors.
2. Select the vendors to contact.
3. Click Bulk Request.
4. Configure the request settings.
5. Review and send.

Templates. The standard template asks for an SBOM in SPDX or CycloneDX, lists the required fields (framed in the docs as EO 14028 compliance), and includes submission instructions and the deadline. To make your own, go to Settings › Request Templates, click Create Template, customise the content and save it. A common pattern is one template per tier.

If you are writing templates now, note that CISA's 2026 Minimum Elements for an SBOM replaced the NTIA 2021 minimum elements in July 2026. Safeguard's docs describe completeness checks in terms of the NTIA minimum elements and EO 14028, so check with Safeguard how the completeness check treats the 2026 elements before you cite them in a template.

Tracking. Each request moves through six statuses:

Automated follow ups. You can configure reminders. The docs describe a first reminder seven days before the deadline, a second at the deadline, and an escalation seven days after it. Missed deadlines are evidence too: the score's operational risk factor uses response time to requests.

Submission routes. Vendors can submit by email attachment or through the secure upload portal, and the docs list integration routes as well.

Validation. When an SBOM arrives, the docs describe five automatic steps:

1. Format validation (valid SPDX or CycloneDX).
2. Completeness check against required fields.
3. Compliance verification against EO 14028 requirements.
4. An automatic vulnerability scan.
5. A notification to the person who sent the request.

Rejection. If the SBOM does not meet the requirements, review the validation failures, click Request Revision, specify the corrections needed, and the vendor receives an update request. Typical reasons are missing transitive components, missing supplier names or versions, or the wrong product version.

If you want a quick look at one vendor SBOM before it enters the formal flow, the Safeguard CLI (GA) can scan an SBOM file locally with safeguard scan --sbom vendor-sbom.cdx.json, writing results as JSON under ./output. That is a convenience for a security engineer, not a substitute for the tracked request, because it leaves no request history against the vendor.

How is the vendor risk score built?

Every vendor gets a risk score from 0 to 100. In TPRM, higher is better:

Be careful when you put TPRM numbers next to other Safeguard numbers. Component level risk scores in the Open Source Manager and ESSCM run the other way, so a high component score is bad news while a high vendor score is good news. Label the direction on every report you send to a committee.

The score draws on four groups of factors, each described in Safeguard's Risk Assessment docs:

• Vulnerability risk, from SBOM analysis: the count of critical vulnerabilities, the count of high vulnerabilities, EPSS scores, and known exploited vulnerabilities (CISA KEV). This is where vulnerability management (GA) and its EPSS and KEV enrichment feed the vendor view.
• Compliance risk, from SBOM quality: the EO 14028 compliance percentage, missing required fields, the age of the SBOM and format validity. An old or thin SBOM lowers the score even when it shows few vulnerabilities, which is the right incentive.
• Component risk, from dependency health: abandoned packages, license compliance and transitive dependency depth.
• Operational risk, from vendor behaviour: response time to requests, update frequency, security incident history and contract compliance.

The docs do not publish the weights between these groups, and we will not guess them. If your SR-6 documentation needs to state the criteria precisely, ask Safeguard for the current scoring description and keep it with your methodology. For a broader view of how scoring methods for software vendors are usually built, see our post on software vendor risk scoring methodology.

Why EPSS and KEV matter here. A vendor SBOM with fifty medium CVEs and none in KEV is a different conversation from one with a single KEV listed CVE in an internet facing component. EPSS adds a forward looking probability of exploitation over the next 30 days, and KEV records exploitation that has already happened. Using both keeps the score from punishing vendors for raw volume. Our companion post on prioritising vulnerabilities with reachability, EPSS and KEV goes deeper on the same signals in your own code.

What you do with the score. The Risk Assessment docs describe four follow on actions:

1. Assessment reports. Select one or more vendors and click Generate Report. The report includes an executive summary, the risk score breakdown, vulnerability details, compliance gaps and recommendations. This is the artefact most teams attach to a vendor review or a renewal decision.
2. Comparative analysis. Compare vendors side by side on scores, vulnerability counts, compliance status and trend over time. This is the "consistent baseline" SR-6 asks for.
3. Risk acceptance. Review the finding, click Accept Risk, give a business justification, set a review date and obtain the required approvals. Safeguard's compliance docs are explicit that a risk acceptance is a decision for a person in the app. The AI assistant and MCP clients can prepare work but never approve, accept or sign off.
4. Remediation tracking. Track requested fixes, vendor commitments, progress updates and verification status, so "the vendor promised a patch" becomes a dated record rather than an email.

What does continuous monitoring alert on, and where do alerts go?

DORA Article 30(3)(e) speaks of monitoring "on an ongoing basis", and IR 2024/2690 point 5.1.6 asks for review after significant changes or incidents. TPRM's Monitoring module keeps working after the SBOM is filed.

What is monitored. The docs list new vulnerabilities affecting vendor SBOMs, vulnerability severity changes, exploit availability updates, CISA KEV additions and component health changes.

Alert types. Configure them under Settings › Monitoring:

Where alerts go. Email, Slack, Microsoft Teams, PagerDuty, or a custom webhook. Route Critical tier alerts to the channel your vendor owners and incident responders actually watch, and keep the webhook for your ticketing or GRC system.

The vendor dashboard shows aggregate risk metrics, the vendors that need attention, recent score changes and upcoming SBOM expirations. Trend analysis tracks risk score trends, vulnerability count trends, remediation velocity and compliance improvements over time.

Reports. Scheduled reports can go out weekly (summary), monthly (vendor review), quarterly (risk assessment) and annually (vendor audit). Ad hoc reports let you pick a date range, vendors and report type, then export as PDF or Excel. The quarterly and annual reports line up neatly with the review cycles most DORA and NIS2 programmes already run.

How do vendor SBOMs get rescanned when new CVEs land?

An SBOM's component list is fixed, but the vulnerabilities attached to it change daily, so the vendor does not have to resend anything for you to learn about a new CVE.

Scheduled re-analysis. The docs let you configure periodic SBOM re-analysis daily (suggested for critical vendors), weekly, monthly or quarterly. Each run re-matches the stored component list against current vulnerability data. A sensible starting point is daily for Critical, weekly for High and monthly for Medium.

Event triggers. Re-assessment can also be triggered by new vulnerability disclosures, major version updates, contract renewals and security incidents. Tie the contract renewal trigger to your DORA review calendar so every renewal starts with a fresh score.

What happens on a match. When a re-scan finds that a component in a vendor SBOM is now affected by a new critical CVE, or that an existing CVE has just been added to KEV, the matching alert fires, the score is recalculated, and the change shows up in the dashboard and trend lines. From there, the remediation tracking flow records what you asked the vendor to do and when.

The docs also describe TPRM sending received SBOMs to Portal for storage and to ESSCM for analysis. Portal (GA, used here in its sense as the SBOM storage and sharing surface, not the free entry tier) is where those documents live by product and version. Our posts on SBOM generation and analysis and vendor SBOM intake and scheduled rescans cover that path in more detail.

How does TPRM connect to the compliance suite's vendor records and questionnaires?

Safeguard's compliance and GRC suite (GA) has its own areas for Vendors, Questionnaires and Risks, alongside Frameworks, Controls, Evidence, Monitoring, Tests, Policies and Connectors. The two products answer different questions:

• TPRM answers "what is inside this supplier's software, how risky is it, and has that changed?" It works from SBOMs and vulnerability data.
• The compliance suite answers "is our supplier management control operating, and can we show the auditor?" It works from controls, policies, questionnaires and evidence.

The TPRM docs list GRC platforms and procurement systems among its integrations, and the vendor portal lets suppliers respond to questionnaires. In practice teams use TPRM's assessment reports, score history and SBOM validation records as evidence for supplier management controls, and use questionnaires for what an SBOM cannot show, such as secure development and incident notification practices.

The docs we read do not describe an automatic one to one sync between a TPRM vendor and a compliance suite vendor record, so plan to keep the vendor names aligned (bulk import from the same source list helps) and confirm with Safeguard how the two records link in your tenant. For the compliance side of the workflow, see continuous compliance in Safeguard.

If you also need to show your own customers your security posture, Safeguard's Trust Center is in early access. It is a separate workflow from vendor intake and we do not cover it here.

A worked example: one Critical tier vendor through a quarter

To make the flow concrete, here is how a mid-sized bank's third-party risk team might run one Critical tier supplier, a provider of a payments processing platform, through a quarter. The vendor and numbers are illustrative.

1. Onboard. The vendor is imported from the DORA register spreadsheet with its products, contract dates and the "SBOM per release" obligation recorded on the contract. TPRM suggests Critical, and the team confirms it with the justification "supports a critical function per our DORA function mapping".
2. Request. A single request goes out with the Critical template, a 21 day deadline, and both CycloneDX and SPDX accepted.
3. Track. The request shows Viewed on day 2 and In Progress on day 5. The vendor submits on day 18.
4. Validate. Format validation passes. The completeness check flags missing supplier names on transitive components. The team clicks Request Revision, and the corrected SBOM arrives a week later and moves to Validated.
5. Score. The vendor scores 64, Medium. Two high CVEs with elevated EPSS pull vulnerability risk down; SBOM quality is good after the revision.
6. Act. The team generates an assessment report and opens a remediation item for the two CVEs with the vendor's committed fix date.
7. Monitor. Daily re-analysis is enabled. Six weeks later one of the two CVEs is added to KEV. The Exploited alert fires to the vendor owner's Slack channel and the score drops below the team's threshold of 55, firing a Risk Change alert too.
8. Close. The vendor ships the fix, submits a new SBOM for the patched release, it validates, and the score recovers. The remediation item is marked verified with dates.
9. Report. The quarterly risk assessment report goes to the ICT third-party risk committee. The register of information entry for this provider is updated by the team with the date of the latest assessment.

No new questionnaire was needed, and every step left a dated record.

What Safeguard does not do

1. It cannot verify code it never saw. TPRM scores what the vendor submits. If an SBOM leaves out a component, Safeguard cannot see that component. Validation checks format and completeness of fields; it does not prove that the SBOM matches the binary you are running. Where that matters, write a right to audit or to receive build evidence into the contract.
2. A vendor can refuse. No tool can force a supplier to send an SBOM. TPRM records the refusal, the missed deadlines and the escalations, and the operational risk factor reflects slow responses, but the means to get the SBOM come from your contract and your purchasing power.
3. It does not replace contractual rights. DORA Article 30 requires specific contract terms, including audit, access and inspection rights and exit strategies. TPRM can store contract documents and SBOM obligations; it cannot create those rights or exercise them for you.
4. It is not your DORA register of information filing. Safeguard's docs do not describe producing the register in the ITS 2024/2956 templates or the ESAs' reporting taxonomy, and they do not cover LEI and EUID validation, function identifiers or substitutability fields. Keep the register in the system you use for supervisory reporting and treat TPRM as the source of assessment dates and evidence.
5. It does not do non-software due diligence. Financial health, ownership, sanctions screening, insurance, data protection terms and physical security are outside TPRM's scope.
6. Scores depend on inputs and are not a verdict. The score is a consistent signal for comparison and alerting. It is not a regulatory classification, and the docs do not publish the factor weights. Your committee still decides whether a vendor is acceptable.
7. It does not fix the vendor's software. Safeguard's autonomous remediation opens pull requests in repositories you connect. It cannot patch a vendor's product. Remediation tracking records what the vendor committed to; the fix has to come from the vendor.
8. Vulnerability data has coverage limits. Matching depends on component identifiers in the SBOM and on public vulnerability data. Proprietary components with no public identifiers will show little or nothing, which is not the same as being safe.

Common mistakes

• Requesting SBOMs from every vendor at once. You will drown in submissions and annoy low risk suppliers. Start with Critical and High tiers, which is also what the docs' tier table suggests.
• Not putting the SBOM obligation in the contract. Under M-26-05 and DORA alike, the practical lever is a contract term. Record it in TPRM's contract fields so you know which requests you can enforce.
• Treating Validated as "safe". Validated means the SBOM is well formed, complete enough and scanned. It says nothing about whether the vulnerabilities found are acceptable.
• Mixing score directions. TPRM's 0 to 100 vendor score is higher is better; component scores elsewhere in Safeguard are not. Label every chart.
• Never letting SBOMs expire. Without an SBOM Expiry threshold, a two year old SBOM keeps producing a reassuring score for a product that has changed completely.
• Citing M-22-18 as current. It was rescinded on 23 January 2026. Federal buyers now work under M-26-05, which leaves SBOM collection to contract terms and risk decisions.

FAQ

Does DORA require SBOMs from ICT third-party providers?

No. DORA does not use the term. It requires due diligence before contracting (Article 28(4)), ongoing monitoring rights (Article 30(3)(e)) and an accurate register of information (Article 28(3)). SBOMs are one practical way to make due diligence and monitoring specific for software, which is why many financial entities write them into contracts for critical providers.

What is the DORA register of information?

It is the register every in-scope financial entity must keep of all its contractual arrangements for ICT services, at entity, sub-consolidated and consolidated levels (DORA Article 28(3)). Commission Implementing Regulation (EU) 2024/2956 sets the templates, including B_05.02 for the ICT service supply chain and B_07.01 for assessments of services that support critical or important functions.

What does NIS2 Article 21(2)(d) require for suppliers?

It requires "supply chain security" measures covering the relationship with each direct supplier or service provider. Article 21(3) adds that entities must consider each supplier's specific vulnerabilities, product quality and secure development procedures. Implementing Regulation (EU) 2024/2690 spells out policies, contract terms, monitoring and a supplier registry for certain digital providers.

Is OMB M-22-18 still in effect?

No. OMB M-26-05, dated 23 January 2026, rescinded M-22-18 and M-23-16. Agencies must still keep a complete software and hardware inventory, may still use the Secure Software Development Attestation Form, and may require a current SBOM upon request through contract terms.

How does Safeguard TPRM calculate a vendor risk score?

Each vendor gets a 0 to 100 score where higher is better, built from vulnerability risk (critical and high counts, EPSS, KEV), compliance risk (SBOM completeness, age and format), component risk (abandoned packages, license compliance, transitive depth) and operational risk (response time, update frequency, incident history, contract compliance). The docs do not publish factor weights.

What happens if a vendor refuses to provide an SBOM?

TPRM records the request history, reminders and escalations, and slow responses affect the operational risk factor. It cannot compel a submission. Your options are contractual: enforce an SBOM clause, accept the risk with a documented justification and review date, or reconsider the relationship.

Can Safeguard TPRM verify that a vendor's SBOM is accurate?

Partly. It validates the format, checks required fields and EO 14028 requirements, and scans the components for vulnerabilities. It cannot prove that the SBOM describes every component in the binary you run, because it never sees the vendor's source or build.

How often does Safeguard re-scan vendor SBOMs?

You choose: daily (the docs suggest this for critical vendors), weekly, monthly or quarterly. Re-assessment can also be triggered by new vulnerability disclosures, major version updates, contract renewals and security incidents.

You are someone else's supplier too

TPRM tells you which supplier products carry vulnerable open source components, but your own products are usually built from the same libraries, and to your customers you are the supplier their DORA or NIS2 programme is assessing. The section below covers how Safeguard helps you fix those components in the software you build and ship, which is also what makes the SBOMs you hand to your own customers hold up under their review.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

Neither demo below walks through the TPRM screens; for those, follow the numbered steps above. They show two everyday ways of working with Safeguard that carry over to supplier risk work.

The first demo shows how to connect Claude to the Safeguard MCP server (GA) with OAuth and choose which tools Claude can use. For a third-party risk analyst, the same connection is how you would ask an assistant to summarise findings or draft a vendor follow up from data you are allowed to see. The assistant prepares the work; approvals such as risk acceptance stay with a person in the app.

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

The second demo is a real Android session with the Safeguard mobile app (early access, beta): you send work to a computer running the Safeguard CLI and approve each command on the phone with Allow once, Allow for turn or Deny. The fit with TPRM is indirect. It is useful when, for example, you want a security engineer's machine to run a local safeguard scan --sbom on a vendor SBOM while you approve the command from your phone.

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

To try Safeguard yourself, download the apps and CLI at safeguard.sh/download and read the product documentation at docs.safeguard.sh. For more on TPRM in particular, see Safeguard TPRM for third-party software risk and a procurement reviewer's vendor checks with Safeguard.

Quick check

Sources

• Regulation (EU) 2022/2554 (DORA), Official Journal text via the EU Publications Office
• Commission Implementing Regulation (EU) 2024/2956, register of information templates
• Directive (EU) 2022/2555 (NIS2), Official Journal text via the EU Publications Office
• Commission Implementing Regulation (EU) 2024/2690, NIS2 technical and methodological requirements
• EBA, preparation for DORA application and the register of information
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-161 Rev. 1 (update 1), full text PDF
• OMB M-22-18, Enhancing the Security of the Software Supply Chain (archived)
• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• NTIA, The Minimum Elements for a Software Bill of Materials (2021)
• CISA, 2025 Minimum Elements for an SBOM (draft for comment)
• CISA, 2026 Minimum Elements for an SBOM
• ENISA, Good Practices for Supply Chain Cybersecurity
• CISA, Known Exploited Vulnerabilities Catalog
• FIRST, Exploit Prediction Scoring System (EPSS)
• Safeguard docs, Third Party Risk Manager
• Safeguard docs, TPRM Vendor Management
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, TPRM Risk Assessment
• Safeguard docs, TPRM Monitoring
• Safeguard docs, Compliance
• Safeguard docs, Requests and approvals
• Safeguard docs, Portal SBOM Repository
• Safeguard, Third Party Risk Manager product page

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