CRA Supplier Due Diligence: Questionnaire & Red Flags

Component due diligence is a manufacturer obligation under Article 13(5) of the Cyber Resilience Act. The full verbatim text:

"For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity."

This page is the operational companion to the manufacturer obligation set. The regulatory framework, role boundaries, and importer-side checks live in the cluster guides: manufacturer, importer, distributor, and who must comply. What follows is the questionnaire, the supplier-type playbooks the cluster pages do not cover (FOSS, cloud, hardware-only, OSS stewards, modified COTS firmware), and the operational scenarios that hit teams in real procurement (supplier ghosting, shared upstream components, post-M&A backlogs, n-tier visibility).

Why Supplier Due Diligence Matters

Even as a manufacturer of your own product, your output includes components from suppliers: third-party software libraries, hardware components, firmware modules, cloud services. Vulnerabilities in those components become your vulnerabilities, and your conformity assessment must consider supply-chain risks.

Article 13(5) makes that assessment explicit. The CRA does not prescribe a questionnaire format, but a written questionnaire is the practical way to document that you checked component security, vulnerability handling, SBOM availability, support commitments, and supplier response paths before integration. Without dated records, you have no story to tell a market surveillance authority about how the component-level risk was handled.

If your role on a given product is also importer (you bring a non-EU manufacturer's product into the EU), the four importer pre-market checks are a separate verification duty. This guide stays focused on the manufacturer-side component diligence.

Due Diligence Framework

Tiered Approach

Not all suppliers require the same level of scrutiny:

SUPPLIER TIER ASSESSMENT

TIER 1 (Critical):
- Components with security functions (crypto, auth, firewalls)
- Core software dependencies
- Hardware with firmware
Assessment: Full questionnaire + documentation review + ongoing monitoring

TIER 2 (Significant):
- Major functionality components
- Network-connected elements
- Data-processing components
Assessment: Standard questionnaire + documentation review

TIER 3 (Standard):
- Non-security components
- Utility libraries
- Peripheral hardware
Assessment: Basic questionnaire + spot checks

TIER 4 (Minimal):
- Commodity components
- Well-established OSS
- Non-connected hardware
Assessment: Basic verification + SBOM inclusion

Assessment Areas

Your due diligence should cover:

The framework is generic, but the evidence each supplier type can actually produce varies. The next five sections work through the most common supplier shapes and the diligence path that fits each one.

FOSS-Specific Supplier Due Diligence

Article 13(5) names FOSS components explicitly: components of free and open-source software that have not been made available on the market in the course of a commercial activity. The legal duty runs whether or not money changes hands. A questionnaire signed in blood by a commercial vendor is not the model when the upstream is a GitHub project with three maintainers.

For non-commercial FOSS components, the evidence set shifts from supplier-attested documents to project-observable signals you can collect yourself.

FOSS COMPONENT DILIGENCE CHECKLIST

PROJECT HEALTH:
[ ] Active commits in last 90 days
[ ] Number of distinct contributors (>1 = bus-factor relief)
[ ] Release cadence stated or observable
[ ] Issue tracker is responsive (median time-to-comment)

SECURITY POSTURE:
[ ] SECURITY.md present with disclosure address
[ ] CVD policy (private security advisory channel, not just an issue)
[ ] CVE history reviewed (NVD, GitHub Security Advisories, OSV)
[ ] SBOM ingredients are themselves recognisable, not deep forks

LICENCE AND PROVENANCE:
[ ] SPDX identifier matches what the package metadata claims
[ ] No licence-incompatible transitive dependency
[ ] Released artefacts have a verifiable provenance (e.g., SLSA, sigstore)

YOUR FALLBACK PLAN:
[ ] Fork target identified if upstream goes silent
[ ] In-house capacity to patch declared (which engineer, what code)
[ ] Replacement candidates listed, with substitution effort estimated

Two operational rules. First, Article 13(6) requires that vulnerabilities you find in a FOSS component are reported to the upstream project and that any fix you produce is shared back, in machine-readable form where appropriate. The questionnaire item you are checking is not the upstream's commitment to you, it is your own commitment to flow vulnerabilities and patches back. Second, a quiet upstream does not extinguish your duty. If the project goes inactive, your fallback plan (fork, in-house patching, replacement) is part of the diligence record, not a future problem.

For projects sustained by a foundation or legal entity acting as an open-source software steward, the diligence pattern changes again. That case is in the next section.

OSS Steward vs Commercial Supplier

A small but important class of upstream is run by an open-source software steward: a legal entity, typically a foundation, whose core purpose is sustaining specific open-source projects intended for commercial use. The Linux Foundation, the Eclipse Foundation, and the Apache Software Foundation are typical examples. Stewards sit under Article 24, not Article 13. The duty set is narrower (a documented cybersecurity policy, a cooperation duty with market surveillance, partial application of Article 14 incident reporting), and the steward is not the manufacturer of any commercial product downstream.

For the manufacturer-vs-steward boundary, see open-source stewards.

The diligence consequence for you, as the downstream integrator, is that the questionnaire shape is different.

What you keep doing: project-health checks, SBOM ingestion, CVE monitoring, your own fork-and-patch fallback. What you stop expecting: contractual vulnerability-notification SLAs, paid support tiers, audit clauses. The diligence record for a steward-sustained component is thinner on supplier paper and heavier on your own controls than for a commercial vendor, and that is the legally correct shape.

Cloud-Service Component Diligence

When the "component" inside your product is an API or a managed service (an authentication SaaS, a managed message broker, a serverless function, a cloud database), the evidence pattern is different again. There is no DoC, no SBOM, no source code you ship. There is a contract, a security attestation portfolio, and a shared-responsibility model.

CLOUD-SERVICE COMPONENT DILIGENCE

SECURITY ATTESTATIONS:
[ ] SOC 2 Type II report (current)
[ ] ISO/IEC 27001 certificate (current, scope check)
[ ] ISO/IEC 27017 (cloud-specific controls) where relevant
[ ] ISO/IEC 27018 (PII in public cloud) where personal data is in scope

OPERATIONAL EVIDENCE:
[ ] Status page with incident history and post-mortems
[ ] Published RTO/RPO and last DR test date
[ ] Sub-processor list and notification process for changes
[ ] Data-processing agreement with EU data residency, where applicable

SHARED RESPONSIBILITY:
[ ] Provider responsibility scope documented
[ ] Your responsibility scope acknowledged (config, identity, secrets, network)
[ ] Logging and audit-trail access for your responsibility scope

CRA-ADJACENT:
[ ] Vulnerability disclosure path for the API itself
[ ] Breach notification clock in the contract (hours, not "promptly")
[ ] Service-discontinuation notice window (typically 12 months)

The CRA does not regulate the cloud provider directly when the provider is not placing a product with digital elements on the market. Your duty under Article 13(5) is to evidence that the cloud dependency does not compromise your product's cybersecurity. The deliverable is the attestation portfolio plus a written shared-responsibility statement, not a CRA-shaped questionnaire.

Hardware-Only and ODM Supplier Diligence

When your contract manufacturer (ODM, EMS, OEM-style assembler) ships physical boards and the firmware is yours, the supplier is providing the hardware substrate but not the security envelope. The CRA places the security envelope on you, the entity flashing and signing the firmware that goes on the board.

The questionnaire here is thinner on software questions and heavier on hardware-trust and supply-chain integrity.

HARDWARE-ONLY / ODM DILIGENCE

HARDWARE TRUST:
[ ] BOM with cryptographic-grade component identification
[ ] Counterfeit-component controls (component sourcing audit)
[ ] Secure-element source and pre-provisioning method
[ ] Factory-key injection process and audit trail

ASSEMBLY INTEGRITY:
[ ] ISO 9001 quality system in place
[ ] Tamper-evidence applied during assembly and shipping
[ ] Lot/serial traceability from factory to receiving dock

FIRMWARE HANDOFF:
[ ] Who signs the firmware: you, the ODM, or both
[ ] First-boot provisioning state (factory defaults, ownership transfer)
[ ] Bootloader and secure-boot chain, who owns each link

POST-SHIPMENT:
[ ] EOL notice window for the hardware platform
[ ] Last-time-buy commitment and length
[ ] Replacement-part availability for the support period you commit to

A common operational error: signing a multi-year support period with an ODM whose hardware EOL window is 18 months. The CRA support-period clock starts when you place the product on the EU market; if the underlying silicon goes EOL inside that window, the support obligation does not transfer to your customer's tolerance.

COTS Firmware You Modify

If you take a commercial off-the-shelf product, modify the firmware, and place the result on the EU market, Article 22 treats you as the manufacturer of the modified product for the part affected by the substantial modification, or for the whole product if the modification touches the cybersecurity envelope.

"A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of a product with digital elements and makes that product available on the market, shall be considered to be a manufacturer for the purposes of this Regulation."

The diligence consequence is large: the original manufacturer's DoC and conformity assessment no longer cover the product as you place it on the market. You inherit the manufacturer duty set for the affected part or whole. The original supplier becomes irrelevant to the CRA file; your own engineering team becomes the answerable party.

The diligence step here is therefore not a questionnaire to the original vendor. It is an internal modification-impact assessment. Document the modification scope, decide whether it is substantial, and treat the whole as manufacturer-scope work if the modification touches authentication, encryption, network surface, or the update mechanism. A clean record of which modification was applied to which unit batch is the artefact a market surveillance authority will ask for first.

The Questionnaire

Use this questionnaire as a starting point for commercial software and hardware vendors. The earlier sections cover the variants for FOSS, OSS stewards, cloud APIs, hardware-only ODMs, and modified COTS firmware.

Section 1: Company Information

SUPPLIER DUE DILIGENCE QUESTIONNAIRE
Section 1: Company Information

1.1 Company Details
    Company Name: _________________________________
    Legal Address: ________________________________
    Country of Incorporation: _____________________
    Primary Contact: _____________________________
    Security Contact: ____________________________

1.2 Business Information
    Years in Business: ___________________________
    Number of Employees: _________________________
    Annual Revenue (range): ______________________

1.3 EU Representation (if non-EU)
    EU Authorised Representative name + address: __
    (For full detail on the AR cascade and importer
    routing when no EU establishment exists, see the
    importer cluster guide:
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Certifications (attach copies)
    [ ] ISO 9001 (Quality Management)
    [ ] ISO 27001 (Information Security)
    [ ] ISO 27701 (Privacy)
    [ ] SOC 2
    [ ] Other: _________________________________

Section 2: Product Compliance

Section 2: Product Compliance

2.1 Product Identification
    Product Name/Model: __________________________
    Version/Revision: ___________________________
    Product Category: ___________________________

2.2 CRA Classification
    [ ] Default
    [ ] Important Class I (Annex III, Part I)
    [ ] Important Class II (Annex III, Part II)
    [ ] Critical (Annex IV)
    [ ] Not yet classified

2.3 Conformity Assessment
    [ ] Module A (Self-Assessment)
    [ ] Module B+C (EU-Type Examination)
    [ ] Module H (Full Quality Assurance)
    [ ] Not yet completed

    If Module B, C, or H:
    Notified Body Name: __________________________
    Certificate Number: __________________________
    Certificate Date: ____________________________

2.4 EU Declaration of Conformity
    [ ] DoC available (attach copy)
    [ ] DoC not yet issued
    Date of DoC: ________________________________

2.5 CE Marking
    [ ] CE marking applied
    [ ] CE marking not yet applied
    If applied, where on product: _________________

2.6 Technical Documentation
    [ ] Technical file available upon request
    [ ] SBOM available (format: ________________)
    [ ] Risk assessment documentation available
    [ ] User/security instructions available

Section 3: Security Practices

Section 3: Security Practices

3.1 Secure Development
    Do you follow a secure development lifecycle?
    [ ] Yes - Describe: __________________________
    [ ] No

    Do you conduct security testing?
    [ ] Static analysis (SAST)
    [ ] Dynamic analysis (DAST)
    [ ] Penetration testing
    [ ] Fuzz testing
    [ ] Other: _________________________________

    Do you have a secure coding standard?
    [ ] Yes - Which: ____________________________
    [ ] No

3.2 Component Management
    How do you track third-party components?
    [ ] SBOM maintained
    [ ] Dependency tracking tool (name: _________)
    [ ] Manual tracking
    [ ] Not systematically tracked

    How do you monitor for vulnerabilities in dependencies?
    [ ] Automated scanning (tool: _______________)
    [ ] Manual CVE monitoring
    [ ] Rely on vendor notifications
    [ ] No systematic monitoring

3.3 Security Architecture
    Describe key security features of the product:
    _____________________________________________

    What cryptographic standards are used?
    _____________________________________________

    How is authentication implemented?
    _____________________________________________

    How is data protected at rest and in transit?
    _____________________________________________

Section 4: Vulnerability Management

Section 4: Vulnerability Management

4.1 Vulnerability Disclosure
    Do you have a coordinated vulnerability disclosure policy?
    [ ] Yes - URL: ______________________________
    [ ] No

    Do you have a security.txt file?
    [ ] Yes - URL: ______________________________
    [ ] No

    What is the security contact method?
    [ ] Email: __________________________________
    [ ] Web form: _______________________________
    [ ] Bug bounty platform: ____________________
    [ ] Other: _________________________________

4.2 Response Commitments
    What is your acknowledgment timeline?
    [ ] Within 24 hours
    [ ] Within 72 hours
    [ ] Within 7 days
    [ ] No commitment

    What is your typical patch timeline for:
    Critical vulnerabilities: ___________________
    High vulnerabilities: _______________________
    Medium vulnerabilities: _____________________

4.3 ENISA Reporting
    Are you prepared for ENISA reporting (Sept 2026)?
    [ ] Yes, process established
    [ ] In progress
    [ ] No
    [ ] Not applicable (not manufacturer)

4.4 Historical Vulnerabilities
    How many security vulnerabilities were reported
    in this product in the past 24 months? ______

    How were they resolved?
    [ ] All patched within stated timelines
    [ ] Some delays (explain): __________________
    [ ] Some remain unpatched (explain): ________

Section 5: Update and Support

Section 5: Update and Support

5.1 Support Period
    What is the committed support period from market
    placement?
    [ ] 5 years (CRA minimum)
    [ ] 7 years
    [ ] 10 years
    [ ] Other: _________________________________
    [ ] Not defined

    When was this product first placed on EU market?
    Date: ______________________________________

    When does the support period end?
    Date: ______________________________________

5.2 Update Mechanism
    How are security updates delivered?
    [ ] Automatic updates (OTA)
    [ ] Manual download from portal
    [ ] Physical media
    [ ] Other: _________________________________

    Are security updates separate from feature updates?
    [ ] Yes
    [ ] No - bundled together

    Can users defer or skip updates?
    [ ] Yes
    [ ] No - mandatory
    [ ] Configurable

5.3 Update Verification
    Are updates signed?
    [ ] Yes - Method: __________________________
    [ ] No

    Can users verify update authenticity?
    [ ] Yes - How: _____________________________
    [ ] No

5.4 End-of-Support Planning
    Do you have a documented EOL process?
    [ ] Yes
    [ ] No

    How will customers be notified of EOL?
    _____________________________________________

    What happens after support period ends?
    [ ] Product continues to function
    [ ] Product loses functionality
    [ ] Product requires migration

Section 6: Documentation Requirements

Section 6: Documentation Requirements

6.1 Available Documentation
    Mark all documentation you can provide:

    [ ] EU Declaration of Conformity
    [ ] Technical file (or relevant excerpts)
    [ ] Software Bill of Materials (SBOM)
        Format: [ ] CycloneDX [ ] SPDX [ ] Other
    [ ] Risk assessment summary
    [ ] Security architecture document
    [ ] User instructions (security-relevant)
    [ ] Vulnerability disclosure policy
    [ ] Support/maintenance terms

6.2 Documentation Delivery
    How will documentation be provided?
    [ ] On request (response time: ____________)
    [ ] Via secure portal
    [ ] Bundled with product
    [ ] Other: _________________________________

6.3 SBOM Details (if available)
    SBOM covers:
    [ ] Direct dependencies only
    [ ] Transitive dependencies included
    [ ] Hardware components (if applicable)

    SBOM update frequency:
    [ ] Per release
    [ ] On request
    [ ] Not systematically updated

Section 7: Contractual Commitments

Section 7: Contractual Commitments

7.1 Compliance Warranty
    Will you warrant CRA compliance in the contract?
    [ ] Yes
    [ ] No
    [ ] Negotiable

7.2 Documentation Retention
    Will you retain technical documentation for 10 years?
    [ ] Yes
    [ ] No
    [ ] Shorter period: ________________________

7.3 Notification Obligations
    Will you notify us of:
    [ ] Security vulnerabilities in the product
    [ ] Changes to conformity status
    [ ] End-of-support decisions
    [ ] Material changes to security architecture

7.4 Audit Rights
    Will you allow compliance audits?
    [ ] Yes - unrestricted
    [ ] Yes - with notice
    [ ] No

7.5 Indemnification
    Will you indemnify for CRA non-compliance?
    [ ] Yes
    [ ] No
    [ ] Negotiable

Section 8: Attestation

Section 8: Attestation

I attest that the information provided in this questionnaire
is accurate and complete to the best of my knowledge.

I understand that [Your Company] is relying on this information
for CRA compliance purposes and that material misrepresentations
may result in contract termination.

Completed by: _____________________________________
Title: ___________________________________________
Date: ____________________________________________
Signature: _______________________________________

Red Flags (Pre-Contract Signals)

These red flags are signals to catch during questionnaire review and contract negotiation, before any purchase order is signed. For the importer-side mirror, applied at the point of placing a non-EU manufacturer's product on the EU market, see what to refuse and why on the importer cluster page.

Critical Red Flags (Disqualify the relationship)

Serious Red Flags (Require negotiated mitigation)

Yellow Flags (Monitor through the relationship)

Verification Process and Monitoring

Initial Verification

1. Document Collection

   • Request DoC copy
   • Request SBOM (or confirmation of availability)
   • Request security contact information
   • Request support period commitment

2. Document Review

   • Verify DoC is signed and complete
   • Check product identification matches
   • Verify CE marking claims
   • Review SBOM format and completeness

3. Compliance Spot-Checks

   • Verify security.txt exists (if web-accessible)
   • Check CVD policy is published
   • Test security contact responds
   • Verify support period claims in documentation

Ongoing Monitoring

SUPPLIER MONITORING SCHEDULE

Monthly:
[ ] Check for published security advisories
[ ] Verify security contact still functional
[ ] Review any vulnerability disclosures

Quarterly:
[ ] Request updated SBOM (if significant releases)
[ ] Verify CVD policy still accessible
[ ] Check for new certifications or lapses

Annually:
[ ] Full questionnaire refresh
[ ] Review support period status
[ ] Verify documentation still available
[ ] Business stability review

Trigger-Based:
[ ] Major security incident → Immediate review
[ ] Ownership change → Full re-assessment
[ ] Product discontinuation → EOL planning
[ ] Contract renewal → Compliance re-verification

When a Supplier Will Not Respond

The single most common operational failure in supplier diligence is not a failed questionnaire response: it is the absence of any response. The supplier ghosts the request, slow-walks for months, or sends a one-line "we comply with all applicable regulations" reply. There is no statutory penalty against the supplier (they have no CRA duty to answer your questionnaire), so the escalation flow has to be commercial and procedural.

SUPPLIER NON-RESPONSE ESCALATION

WEEK 1: Initial questionnaire sent
        Reasonable response window: 15 business days for Tier 1,
        30 business days for Tier 2, 45 for Tier 3-4.

WEEK 3: First follow-up to the named security contact and the
        primary commercial contact. CC procurement lead.

WEEK 5: Escalation to the supplier's account executive and to
        your own procurement director. Set a hard date.

WEEK 7: If still no substantive response:
        a) Document the non-response in the supplier file
        b) Mark the component "compliance-unverified"
        c) Trigger replacement-supplier evaluation
        d) Notify product owners depending on the component

WEEK 9: Decision gate.
        Substantive response received → proceed to review.
        No response → switch to replacement supplier and
        document the switch as a CRA-driven decision.

Non-response is itself diligence evidence. A market surveillance authority asking why you discontinued a supplier will accept a documented escalation trail and a switch decision far more readily than a vague "they were difficult to work with". The artefact you keep is the dated escalation log plus the decision memo.

Shared Upstream Components and Coordinated Vetting

When multiple manufacturers integrate the same upstream component (a widely used cryptography library, a common image-processing SDK, a popular embedded OS), each downstream manufacturer carries its own Article 13(5) duty. The duty does not transfer to the most diligent peer, and "everyone else uses it" is not a defence.

There are two coordination patterns that reduce duplicate work without offloading the duty:

The diligence record should name the shared-vetting source explicitly: "review report from [working group], dated [X], reviewed and accepted on [Y], gaps tracked in [system]". A copy-paste from a peer's diligence file is not a substitute for your own decision record.

Post-M&A: Inherited Supplier Relationships

When your company acquires another company, you also acquire its supplier list. A common post-M&A reality is dozens or hundreds of supplier relationships with no CRA-shaped diligence record at all. The work cannot be done overnight, but a triage is achievable inside a single quarter.

POST-M&A SUPPLIER TRIAGE (90 DAYS)

DAY 1-15: Inventory
[ ] Pull supplier list from acquired entity's ERP / procurement system
[ ] Cross-reference to current product BOMs
[ ] Identify which suppliers feed into CRA-scope products
[ ] Drop out-of-scope suppliers from active triage

DAY 15-30: Tiering
[ ] Apply your tier model to the inherited list
[ ] Tag suppliers with no existing diligence record
[ ] Flag suppliers whose products fall in Important Class II or Critical

DAY 30-60: Tier-1 questionnaires
[ ] Send the questionnaire to every Tier-1 supplier without a record
[ ] Re-issue to any Tier-1 supplier whose record is older than 24 months
[ ] Capture responses centrally

DAY 60-90: Decision gate
[ ] Tier-1 suppliers with passing responses → integrated
[ ] Tier-1 suppliers with red flags → mitigation plan or replacement
[ ] Tier-2/3 suppliers → schedule into the standard annual cycle

ONGOING:
[ ] Roll inherited suppliers into your normal monitoring schedule
[ ] Tag the acquired-via-M&A origin in the supplier record for audit

The CRA does not give an M&A grace period; the acquiring entity inherits the manufacturer obligation on the date the acquisition closes, on the components currently in shipped product. The triage above is the practical compromise: prove that a defensible diligence programme is running, even if the full record is being rebuilt.

N-Tier Subcontracting Visibility

Your Tier-1 supplier may itself subcontract to a Tier-2 supplier, which in turn integrates components from a Tier-3 upstream. The CRA duty is yours regardless of where in the chain the vulnerability originates. Practical visibility, however, runs out fast beyond Tier 1.

Three concrete controls that buy real n-tier visibility:

• Transitive SBOM clause. Contract requires the supplier's SBOM to include transitive dependencies, not just direct dependencies. A direct-only SBOM hides almost all of the actual risk surface.
• Sub-processor / subcontractor list. Contract requires the supplier to disclose and update the list of named subcontractors that touch security-relevant parts of the component. The clause does not give you a veto, but it gives you visibility.
• Vulnerability pass-through. Contract requires that the supplier flow vulnerabilities discovered in transitively integrated components to you on the same timeline as vulnerabilities in directly developed code.

Without a transitive SBOM, you cannot run dependency-tree scans against the component, and you cannot demonstrate to a market surveillance authority that the n-tier risk was assessed. Without a sub-processor list, an upstream change of subcontractor (with its own provenance, controls, and bus-factor) is invisible to you. Without vulnerability pass-through, the Tier-1 supplier's silence on a Tier-2 issue becomes your silence on a security incident.

Supplier Agreement Clauses

Include these provisions in supplier contracts. Each clause is the contractual hook for one of the diligence outcomes above.

Compliance Representation:

Supplier represents and warrants that the Product(s)
comply with Regulation (EU) 2024/2847 (Cyber Resilience
Act) and that Supplier has completed the required
conformity assessment.

Documentation Provision:

Supplier shall provide upon request:
(a) Copy of EU Declaration of Conformity
(b) Software Bill of Materials in [CycloneDX/SPDX] format,
    including transitive dependencies
(c) Technical documentation relevant to Buyer's
    compliance obligations
Response time: [5 business days]

Vulnerability Notification:

Supplier shall notify Buyer within [24/48] hours of
becoming aware of any security vulnerability in the
Product(s) or in any transitively integrated component
that:
(a) Is actively exploited, or
(b) Has a CVSS score of 7.0 or higher, or
(c) Is subject to public disclosure

Support Period Commitment:

Supplier commits to providing security updates for
the Product(s) for a minimum period of [5/7/10] years
from the date of first market placement in the EU.

SBOM Updates:

Supplier shall provide an updated SBOM within [10]
business days of each product release that includes
changes to direct or transitive third-party components.

Audit Rights:

Buyer may audit Supplier's compliance with this
Agreement and applicable CRA requirements upon
[30 days] written notice, no more than once per year
unless triggered by a compliance concern.

Subcontractor Disclosure:

Supplier shall maintain and provide upon request a list
of subcontractors that contribute to or have access to
security-relevant components of the Product(s). Supplier
shall notify Buyer of any material change to that list
within [30] days.

Common Mistakes

Relying on Self-Attestation

Problem: Accepting a supplier's verbal assurances without documentation.

Fix: Always obtain written evidence. No DoC copy, no purchase. A signed questionnaire is the floor, not the ceiling.

One-Time Assessment

Problem: Due diligence at contract signing only.

Fix: Implement the monitoring schedule above. Compliance state changes; questionnaires expire.

Ignoring Tier 3-4 Suppliers

Problem: Only assessing "major" suppliers while ignoring smaller ones.

Fix: Even minor components introduce vulnerabilities (the log4j lesson). Scale the assessment; do not skip the tier.

No Contractual Backing

Problem: Relying on supplier goodwill without contract terms.

Fix: Put compliance obligations in writing. The clauses above are the floor.

Waiting Until December 2027

Problem: Starting supplier assessments right before the CRA application date.

Fix: Start now. Vendor responses lag. Non-compliant suppliers need months to remediate or be replaced.

Supplier Due Diligence Checklist

SUPPLIER DUE DILIGENCE CHECKLIST

PRE-ENGAGEMENT:
[ ] Supplier tier determined (1/2/3/4)
[ ] Supplier type determined (commercial, FOSS, OSS steward,
    cloud, hardware-only, modified COTS)
[ ] Appropriate questionnaire variant selected
[ ] Internal reviewer assigned

INITIAL ASSESSMENT:
[ ] Questionnaire sent
[ ] Questionnaire received and reviewed
[ ] Red flags identified and addressed
[ ] Documentation collected:
    [ ] EU Declaration of Conformity (or N/A reason)
    [ ] SBOM with transitive dependencies (or availability confirmed)
    [ ] CVD policy
    [ ] Support period commitment
[ ] Spot-checks completed:
    [ ] security.txt verified
    [ ] Security contact tested
    [ ] CE marking verified

CONTRACT NEGOTIATION:
[ ] Compliance clauses included
[ ] Documentation provisions agreed
[ ] Vulnerability notification terms set (hours, not "promptly")
[ ] Support period commitment secured
[ ] Audit rights included
[ ] SBOM update schedule agreed
[ ] Subcontractor disclosure clause included

POST-CONTRACT:
[ ] Monitoring schedule established
[ ] First documentation delivery confirmed
[ ] Contacts registered in supplier management system
[ ] Review dates calendared

ONGOING:
[ ] Monthly checks completed
[ ] Quarterly reviews completed
[ ] Annual reassessment completed
[ ] Trigger events handled (incident, ownership change, EOL)

Related Guides

• How to Generate a CRA-Compliant SBOM: Tools, Formats, and CI/CD Integration
• The CRA Manufacturer Guide
• CRA Distributor Checklist

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.