CRA Art.16: Importer Obligations — How US-Hosted Components Create EU Compliance Chain Liability

Post #14 in the sota.io CRA Developer Series

Most CRA compliance conversations focus on manufacturers. Article 3(13) of the Cyber Resilience Act defines a manufacturer as anyone who develops or manufactures a product with digital elements for their own use or places it on the market. EU startups building SaaS products read that and think: "That's me. I need to comply."

But CRA creates a second compliance category that gets far less attention: importers.

Article 16 defines importers and their obligations. For EU software companies using third-country (i.e., US-headquartered) cloud services, PaaS providers, or SaaS dependencies as components of their products, Article 16 creates a compliance chain problem that is difficult to solve without restructuring your infrastructure stack.

This post breaks down what Art.16 actually requires, why it matters for developers (not just physical goods importers), and why CLOUD Act jurisdiction makes compliance structurally complicated when your upstream is US-hosted.

Who Is an Importer Under CRA?

Article 3(17) defines an importer as:

"Any natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a person established outside the Union."

The physical goods intuition here — somebody shipping hardware from China — misses the software reality. In practice, an EU company that bundles or relies on US-origin software components as part of a product they place on the EU market can qualify as an importer of those components.

Consider the chain:

1. US PaaS provider (AWS Lambda, Google Cloud Run, Azure Functions) — established outside the Union
2. EU startup builds a product with digital elements on top of that PaaS — established in the Union
3. EU startup places the combined product on the EU market — under that product's name and trademark

Under CRA's framework, the EU startup is the manufacturer for the final product and potentially the importer for the underlying third-country components it uses and passes through to end users.

The European Commission's guidance clarifies that the CRA's supply chain obligations are intentionally layered: manufacturers must address vulnerabilities in all components, and importers serve as the accountability gateway for non-EU-origin elements entering the EU market.

What Article 16 Actually Requires

Article 16 places several concrete obligations on importers before placing a product on the market:

1. Conformity Verification

Importers must verify that the manufacturer has:

• Carried out the relevant conformity assessment procedure (Art.32)
• Drawn up the technical documentation (Art.31 + Annex V)
• Affixed the CE marking to the product
• Is identified on the product or its packaging
• Has established a coordinated vulnerability disclosure policy (Art.14)

For physical goods, this is straightforward: you get the CE certificate, check the technical file, ship the product. For software components — particularly cloud services — this verification is considerably more complex, because most US-based cloud providers have not undergone CRA conformity assessment and cannot demonstrate CRA compliance documentation.

The problem: If your EU product relies on AWS Lambda functions, Google Firebase, or Twilio communications infrastructure as material components, and those providers have not completed CRA conformity assessment by September 2026, you — as the importer — cannot discharge your Art.16 verification obligation. You are placing a non-compliant product on the EU market.

2. Record-Keeping for 10 Years

Article 16(3) requires importers to:

"Keep a copy of the EU declaration of conformity at the disposal of the market surveillance authorities for ten years after the product with digital elements has been placed on the market."

This 10-year documentation requirement applies to the conformity documentation of the components you imported. If you are an EU startup that used AWS Cognito as your authentication layer in a product placed on the market in September 2026, you need to be able to produce the AWS Cognito CRA conformity documentation to EU market surveillance authorities until 2036.

The CLOUD Act collision: AWS's compliance documentation is subject to US jurisdiction. Under 18 U.S.C. § 2713 (the CLOUD Act), US authorities can compel disclosure of data held by US companies regardless of where that data is stored. More importantly for importers: the inverse problem is that EU market surveillance authorities requiring documentation from a US parent company face the US legal system as an intermediary. Amazon's documentation is accessible to EU importers — but if that documentation contains anything that US authorities later consider sensitive, the CLOUD Act creates a legal environment where documentation availability becomes legally contingent.

3. Market Withdrawal Obligations

Article 16(4) states that importers who believe a product does not conform to the essential requirements must:

• Not place the product on the market
• Inform the manufacturer and the relevant market surveillance authorities
• Cooperate with the manufacturer to bring the product into conformity

In software terms: if you discover that a US-hosted component you are using fails to meet CRA Annex I essential requirements (particularly the vulnerability handling requirements of Section 2), you have a legal obligation to:

1. Stop shipping the product until the component is replaced or brought into conformity
2. Notify the relevant national market surveillance authority (in Germany: BSI; in France: ANSSI; in the Netherlands: RDI)
3. Notify the non-conforming manufacturer

For EU startups whose products are deeply integrated with US cloud services, this creates a material business risk: a CRA compliance failure by your upstream US provider can force a product withdrawal obligation on your side.

4. Safety Information and Instructions

Article 16(6) requires importers to ensure that the product is accompanied by the instructions and information required by Annex II, in a language that can easily be understood by users.

This pulls in the CRA Annex II documentation requirements (covered in our CRA Annex II post): support period declaration, vulnerability reporting contact, known vulnerabilities at time of release, and the 14 mandatory security disclosures.

Key implication: As an importer, you cannot pass through undocumented components. If your upstream US provider does not supply Annex II-compliant documentation for their components, you must either generate it yourself or substitute an alternative.

The Software Supply Chain as an Import Chain

Most CRA commentary focuses on the relationship between software manufacturers and end users. Article 16 adds a third relationship: the software supply chain.

When EU developers build products that incorporate US-origin cloud components, libraries, or services, the CRA treats this as a distributed import chain. The obligations do not disappear at the component boundary — they cascade up to the product manufacturer.

The Integration Point Matters

The CRA distinguishes between:

• Components that are "integrated" into the final product (covered under the manufacturer's conformity assessment)
• Components that are "placed on the market independently" (must demonstrate their own conformity)

For cloud PaaS services like AWS Lambda or Google Cloud Run, the service is "placed on the market independently" — it is a standalone commercial offering. This means:

1. AWS/Google must demonstrate CRA conformity for their services independently
2. EU developers using those services as material components are importing a non-EU product
3. EU developers must verify conformity (Art.16) before placing their final product on the EU market

The practical result: EU companies building on US-hosted PaaS must either (a) verify their upstream's CRA certification before September 2026, or (b) restructure to use EU-native components that can demonstrate compliance.

What US-Hosted Components Cannot Provide

Even if US cloud providers invest in CRA compliance certification, structural CLOUD Act issues remain unresolvable:

Vulnerability Record Accessibility

Article 16(3) requires importers to keep conformity documentation accessible to market surveillance authorities for 10 years. Article 9 (post-market monitoring) requires manufacturers to keep investigation records. If the underlying component's vulnerability records are held by a US parent company, those records are subject to CLOUD Act disclosure to US authorities — without EU legal process, without prior notice to the EU importer.

This creates a conflict: EU market surveillance authorities require records that the importer must maintain, but those same records may be subject to disclosure to a foreign government without the importer's knowledge or consent.

24-Hour Notification Conflicts

CRA Art.11 requires 24-hour ENISA notification for actively exploited vulnerabilities. But if the EU importer discovers a vulnerability in a US-hosted component at 11:00 PM Friday, and the US provider's incident response team is based in Seattle (UTC-7), the 24-hour notification window creates a coordination problem across jurisdictions. More critically: CLOUD Act gag orders can accompany US national security investigations, potentially preventing a US provider from disclosing vulnerability details to its EU customers during the notification window.

An EU importer relying on a US-hosted component for its product cannot guarantee that it will receive the information necessary to meet Art.11's 24-hour notification requirements when that information is controlled by a US entity.

Withdrawal Orders

If an EU market surveillance authority issues a withdrawal order for a product, the importer is obligated to cease supply immediately. For products integrated with US-hosted components, immediate withdrawal may require disabling accounts, revoking API access, or taking infrastructure offline — actions that may conflict with US commercial contracts, SLAs, or in extreme cases, US legal orders.

The Conformity Assessment Bottleneck

Articles 32-33 of the CRA define the conformity assessment procedures. For most products with digital elements, manufacturers can self-assess conformity (internal production control). For Class I products (higher risk, listed in Annex III), a notified body assessment may be required.

The challenge for EU importers of US components: there is no CRA-certified notified body in the US, and the conformity assessment infrastructure is EU-based by design. US companies wishing to sell into the EU market must either:

1. Establish an EU-based authorized representative (Art.18)
2. Undergo conformity assessment through EU-recognized notified bodies
3. Use a US Conformity Assessment Body (CAB) if one becomes recognized — currently none exist under CRA

Until US cloud providers complete CRA conformity assessment through EU-recognized processes, EU importers cannot discharge their Art.16 verification obligations. This bottleneck is structural, not administrative.

Practical Implications for September 2026

The CRA applies from 11 September 2026. Importer obligations under Art.16 apply from the same date. EU companies relying on US-hosted components have a compliance decision to make before that deadline:

Option 1: Verify and Document

If your US component provider commits to CRA conformity assessment before September 2026, you can:

• Obtain and archive their EU Declaration of Conformity
• Verify Annex I essential requirements coverage
• Confirm Art.14 coordinated vulnerability disclosure policy exists
• Keep records for 10 years from product placement date

This works only if your US provider actually completes certification. Given the scale of the task, many US providers will not complete assessment before the deadline.

Option 2: Treat Components as Non-Conforming

If your US component provider cannot demonstrate CRA conformity by September 2026, your options under Art.16(4) are:

• Withdraw your product from the EU market until conformant components are available
• Replace the non-conforming component with an EU-origin or CRA-certified alternative
• Assume the conformity obligation yourself (by becoming the de facto manufacturer of the combined product and self-assessing — which requires you to document and warrant the component's behavior)

Option 3: Restructure to EU-Native Stack

The cleanest solution from a compliance perspective: build on components that are already within EU legal jurisdiction and can demonstrate CRA compliance through EU-based conformity assessment.

EU-native PaaS providers operating entirely within EU legal entities do not create importer obligations because the manufacturer (or their authorized representative) is already established in the Union. The Art.16 import chain simply does not arise.

The Authorized Representative Route

Article 18 of the CRA creates an alternative pathway: a manufacturer established outside the Union may appoint an authorized representative — an EU-established entity — to fulfill certain obligations on their behalf.

The authorized representative must:

• Verify that the EU Declaration of Conformity and technical documentation have been drawn up
• Keep a copy of the EU DoC at the disposal of market surveillance authorities
• Report non-conformities to the manufacturer and cooperate with authorities

Important: The authorized representative does not assume full manufacturer liability. They are a compliance gateway, not a compliance guarantor. EU importers cannot substitute an authorized representative relationship for their own Art.16 obligations.

For major US cloud providers (AWS, Google, Microsoft Azure), authorized representative arrangements may be the practical path to EU market access. Watch for announcements from these providers as September 2026 approaches.

How EU-Native Infrastructure Simplifies the Compliance Chain

When EU companies build on EU-native infrastructure, the CRA compliance chain becomes linear:

• EU manufacturer (you) → builds on
• EU infrastructure provider → operates under EU legal entity
• EU conformity assessment → through EU-recognized processes
• EU market surveillance → direct access to all relevant parties

There is no import step, no Art.16 obligation, and no CLOUD Act conflict. The manufacturer's own conformity assessment (Art.32) covers the product, and the infrastructure provider's CRA compliance (once certified) closes the supply chain loop.

For sota.io customers, this is the architecture by design. Infrastructure operating entirely within EU legal jurisdiction, without US parent company structure, means:

• No importer obligations cascade to your product
• No CLOUD Act exposure in conformity documentation
• No US jurisdiction conflict in vulnerability notification workflows
• Direct EU-to-EU market surveillance authority relationships

Checklist: Art.16 Importer Obligations for EU Developers

Before placing your product on the EU market in September 2026, verify:

• Identify all third-country components in your product (libraries, APIs, cloud services, SaaS integrations from non-EU entities)
• Request CRA conformity documentation from each third-country supplier before the September 2026 deadline
• Verify essential requirements under CRA Annex I for each component
• Confirm Art.14 CVD policy exists for each third-country component supplier
• Establish 10-year record-keeping for conformity documentation of all imported components
• Document the import chain in your technical file (who supplied what, what conformity documentation exists)
• Assess withdrawal risk — if a component cannot demonstrate conformity, what is your contingency?
• Review commercial contracts with US providers for CLOUD Act conflict provisions
• Evaluate EU-native alternatives for components where conformity is structurally impossible (CLOUD Act jurisdictions)

What Comes Next in the CRA Series

This is Post #14 in the sota.io CRA Developer Series. We've now covered:

• CRA Art.10: Vulnerability Reporting
• CRA Art.14: Coordinated Vulnerability Disclosure
• CRA Penalty Framework
• CRA Art.13: Security by Design
• CRA Art.11: Actively Exploited Vulnerabilities
• CRA Art.7: Vulnerability Handling Requirements
• CRA SBOM Requirements
• CRA Annex I Essential Requirements
• CRA September 2026 Countdown
• CRA Art.6: Product Classification
• CRA Annex II: User Documentation
• CRA Art.12: User Notification Requirements
• CRA Art.9: Post-Market Monitoring

Next: CRA Conformity Assessment — the Art.18-33 framework for CE marking, notified bodies, and self-assessment.

The Cyber Resilience Act creates compliance obligations across the entire supply chain. EU companies acting as importers of third-country software components cannot delegate those obligations to their upstream providers — they must verify, document, and remain accountable. Building on EU-native infrastructure eliminates the importer category entirely, simplifying both your compliance burden and your exposure to CLOUD Act jurisdictional conflicts.