What Is the EU CRA (Cyber Resilience Act)? Vulnerability Reporting Obligations, SBOM, and Compliance Timeline Explained

Does your product connect to the internet, run firmware, or ship with software—and sell into the EU? Then September 11, 2026 is a date worth putting on the company calendar right now. According to a 2026 announcement by TWCERT/CC, the vulnerability reporting obligations under Article 14 of the EU Cyber Resilience Act (CRA) will become mandatory on that day.

How tight are the deadlines? Once a manufacturer becomes aware that a vulnerability in its product is being actively exploited, it must issue an early warning within 24 hours. The cost of non-compliance is equally concrete: fines of up to EUR 15 million or 2.5% of global annual revenue, and the product may even be pulled from the market (TWCERT/CC, 2026).

What makes this worse is that most people are not ready. A survey published in June 2026 by Linux Foundation Research and OpenSSF found that of 843 respondents working in the software industry and open-source community, 66% said they were unfamiliar with the CRA (iThome, 2026). This article pulls everything together in one place: what the CRA is, the Article 14 reporting timeline, the SBOM requirements, the penalty risks, the exposure scenarios for Taiwanese companies exporting to the EU, and a readiness checklist you can act on right away.

What Is the CRA? Scope and Core Requirements of the EU Cyber Resilience Act

The CRA (Cyber Resilience Act) is the EU's cybersecurity regulation for digital products. It applies to all products with digital elements placed on the EU market, and to their manufacturers (TWCERT/CC, 2026). Its core logic is simple: if a product is sold in the EU, its security is the manufacturer's legal responsibility—from design through market launch to vulnerability handling.

Sounds like "yet another EU regulation"? Unlike rules aimed at organizations and personal data, the CRA targets the product itself. A connected camera, a piece of firmware, a mobile app, a software module embedded in hardware—anything with digital functionality that enters the EU market falls within its reach.

Scope: It Follows the Product Flow, Not the Company's Nationality

This is the point Taiwanese businesses most often misjudge. The CRA's applicability test is "does the product enter the EU market"—not where the company is registered. Whether your company is headquartered in Hsinchu, Taipei, or Tainan makes no difference to the answer; as long as the product is exported to the EU, the manufacturer's obligations attach.

What counts as a "product with digital elements"? The scope is broader than intuition suggests. Beyond the visible connected devices and software, the firmware inside a product, bundled cloud connectivity features, and external programmatic interfaces can all constitute digital elements. If you are not yet familiar with the concept of programmatic interfaces, start with our beginner's guide to what an API is, then come back and take inventory of your own products.

The CRA's Three Layers of Core Requirements

Break the act apart and the manufacturer's obligations fall roughly into three layers:

• At the design stage: the product must meet baseline security requirements before it ships—no "sell first, patch later."
• After market launch: vulnerabilities must be handled and security updates provided on an ongoing basis; responsibility does not end at shipment.
• When an incident occurs: when a vulnerability is being actively exploited, it must be reported to the authorities within the Article 14 deadlines.

The third layer—the reporting obligation—is the part that becomes mandatory on September 11, 2026, and the one under the greatest time pressure right now.

CRA Article 14 Vulnerability Reporting Obligations: The 24-Hour, 72-Hour, 14-Day Three-Stage Timeline

According to the 2026 TWCERT/CC announcement, Article 14 vulnerability reporting obligations under the CRA become officially mandatory on September 11, 2026: once a manufacturer becomes aware of "active exploitation" of a vulnerability, it must issue an early warning within 24 hours, submit a detailed vulnerability impact assessment within 72 hours, and file a final report within 14 days of corrective measures becoming available (TWCERT/CC). The three deadlines are tightly chained—miss the first one and everything downstream collapses with it.

What exactly must be submitted, and when? See the table:

Stage	Deadline	What to Submit
Early warning	Within 24 hours of discovering active exploitation	Early warning notification
Detailed report	Within 72 hours	Detailed vulnerability impact assessment
Final report	Within 14 days of corrective measures becoming available (extended to one month for significant incidents)	Final report

(Source: TWCERT/CC, 2026)

The 24-Hour Clock Starts at "Discovery"—What's Really Being Tested Is Your Detection and Escalation Chain

Note the starting point: it is the moment the manufacturer "discovers" active exploitation, not the moment the vulnerability came into existence. What does that mean? What is really being tested is not your form-filling speed, but your detection capability and internal escalation chain. When an engineer receives an anomaly alert in the middle of the night, how long does it take to become a report draft in the hands of your security contact? If that chain has never been rehearsed, 24 hours is in fact extremely short.

In our experience helping clients map their cloud assets, the most common situation is this: the technical team knows the system is in trouble, but nobody can answer "who reports it, in what format, to which authority." The chain breaks at the organizational layer, not the technical one.

Where Do Reports Go? The SRP Platform, CSIRTs, and ENISA

The reporting channel has also been settled: submissions go through the EU's single reporting platform (SRP), and the recipients are the local CSIRT (Computer Security Incident Response Team) and the EU cybersecurity agency ENISA (TWCERT/CC, 2026). For Taiwanese manufacturers, this means the reporting workflow needs to be written into the incident response playbook in advance—if you only start googling "how does the SRP work" when the incident hits, the clock will burn out long before you finish.

SBOM (Software Bill of Materials): The Hidden Prerequisite for CRA Compliance

In its 2026 announcement, TWCERT/CC positioned the SBOM (Software Bill of Materials) as "the de facto hidden prerequisite" for CRA compliance in practice, and recommended adopting the CycloneDX or SPDX international standard formats (TWCERT/CC, 2026). The statute does not demand it in bold capital letters, but without one, the Article 14 deadlines are nearly impossible to meet.

Why? Look back at the 72-hour gate. A detailed vulnerability impact assessment presupposes that you know which products and which versions use the affected component. Teams without an SBOM end up manually digging through code, calling suppliers, and guessing at dependencies when the incident hits—within 72 hours they cannot even finish the inventory, let alone the assessment.

What Is an SBOM? Start by Listing the Ingredients

Think of it as the ingredient label on food packaging. An SBOM lists every software component in your product: open-source packages, third-party libraries, version numbers, dependency relationships. When a vulnerability advisory drops, you check the list and know whether you are affected—instead of mobilizing the whole company for a needle-in-a-haystack hunt.

Which format should you pick? CycloneDX and SPDX are the two international standards named by TWCERT/CC, and they offer the best compatibility when exchanging documents with supply chain partners upstream and downstream. The practical advice: pick one, have your toolchain generate it automatically, and update it with every release—do not hand-craft it once and let it gather dust.

Start the Inventory with Your APIs and Cloud Dependencies

For many teams the blind spot is not the code they wrote, but the external services they consume. Which cloud services does your product call? Which AI model interfaces does it integrate? Where are the keys stored? In our hands-on work organizing clients' AI API assets, just the step of "list every external API the company currently uses and who owns each one" routinely takes days—accounts are scattered, billing is scattered, documentation is missing. Nobody treats it as a problem day to day, and it all surfaces the moment a list is due. If your team uses multiple providers at once, see the unified management approach with an AI API management platform to first pull your assets into one visible place.

---

Not Sure How to Inventory Your Software Components and API Dependencies?

The first step toward an SBOM is laying your cloud and AI API assets out where you can see them. The CloudInsight technical team has long helped Taiwanese enterprises organize multi-platform cloud and AI API procurement, and can start from asset inventory to help you establish the baseline for a security compliance assessment.

👉 Contact our technical team

---

CRA Penalties and Business Risk: Up to EUR 15 Million or 2.5% of Global Annual Revenue

The ceiling for CRA violations is EUR 15 million or 2.5% of global annual revenue, whichever is higher; on top of that, the product may face removal from the market, recall, or sales restrictions (TWCERT/CC, 2026). Note the words "global annual revenue"—the calculation base is not your EU revenue, but the entire company's worldwide income.

The fine figures are scary enough, but for most Taiwanese companies, the truly lethal part may be the second half of the sentence.

Think it through: what happens if your product is restricted from sale in the EU? Channel partners re-evaluate the relationship, brand customers activate alternative suppliers, follow-on orders freeze. A fine is one-off; loss of market access cascades. For hardware makers and contract manufacturers already running on thin margins, the cost of being shut out of the EU market far exceeds the fine on paper.

There is also a less-discussed layer of risk: pass-through requirements from the procurement side. To stay compliant themselves, EU customers will push security and documentation requirements up the supply chain. In other words, even if your product does not enter the EU under your own brand, as long as you sit anywhere on that supply chain, CRA pressure will find you through contract clauses.

Who Is Affected by the CRA? Scenarios for Taiwanese Software and Connected-Product Exporters

The blast radius is bigger than most people assume, and the awareness gap is striking. The Linux Foundation Research and OpenSSF report published in June 2026 noted that the survey, conducted in early 2026, interviewed 843 software industry and open-source practitioners across Europe, North America, and Asia-Pacific—and 66% said they were unfamiliar with the CRA (iThome, 2026). If two-thirds of people inside the industry are unfamiliar with it, you can imagine the readiness level of the average exporter.

How exactly will Taiwanese businesses get swept in? We break it into three scenarios by product flow.

Scenario 1: Own-Brand Connected Hardware Exported to the EU

The most direct category. Connected cameras, smart appliances, networking equipment, industrial control devices—if it enters the EU market under your own brand, the full set of manufacturer obligations lands on you: security requirements at the design stage, update responsibilities after launch, and the Article 14 reporting deadlines. None of it can be dodged. These companies have the heaviest homework and the strongest reason to rehearse their reporting workflow before September 2026.

Scenario 2: ODMs, Component and Module Suppliers

You do not ship to the EU directly, but your module sits inside a customer's product that does? Then the pressure arrives in the form of "customer requirements": SBOMs, vulnerability-reporting cooperation clauses, security documentation. Our observation is that these supply chain contract updates tend to arrive well before the regulation's effective date—brand customers will not wait until September 11 to start asking for documents.

Scenario 3: Software and SaaS Entering the EU Market with a Product

Software companies tend to underestimate their exposure. The CRA applies to "products with digital elements," and software itself is a textbook target; software modules embedded in hardware and apps shipped with devices count just the same. If your software enters the EU market in any form, now is the time to confirm your role and obligations in the supply chain—rather than assuming "we're a software company, so we're fine."

The same logic applies to your own procurement side: when you purchase cloud and AI services, whether the vendor can support your compliance documentation needs directly affects whether you can answer to your own customers. For enterprise vendor-selection logic, see the AI API enterprise procurement guide.

---

Procuring Cloud and AI Services Is Part of Your Compliance Paper Trail, Too

Whether a vendor can produce formal contracts, government uniform invoices, and local technical support directly affects the completeness of your supply chain documentation. CloudInsight resells AWS, GCP, Azure, and other cloud services along with mainstream AI APIs, with Taiwan enterprise contracts and Chinese-language support, helping you bring the procurement side into an audit-ready state.

👉 Consult on enterprise plans now｜Join us on LINE for real-time consultation

---

CRA Compliance Readiness Checklist: 7 Things Enterprises Can Do Right Now

The countdown to the September 11, 2026 enforcement date is measured in months (TWCERT/CC, 2026). The good news: none of the seven items below needs to wait for a consultant's report, and every one of them maps directly to some part of Article 14.

1. Inventory your product lines' EU exposure: List which products (including software, firmware, and modules) enter the EU market in any form. Answer "does this even apply to me" first, so the investment that follows has direction.
2. Build and maintain an SBOM: Pick CycloneDX or SPDX, generate it automatically from your toolchain, and update it with every release. A hand-maintained list goes stale within three months.
3. Set up vulnerability intelligence monitoring: Subscribe to vulnerability advisories for the components you use, so the "discovery" clock does not start much later for you than for the attackers.
4. Rehearse the 24/72-hour reporting workflow: Designate a reporting owner, prepare report templates, confirm how submissions work on the SRP platform, then actually run a tabletop exercise. A workflow that has never been rehearsed will fall apart on the day it matters.
5. Review supply chain contract clauses: Can your upstream suppliers provide SBOMs and vulnerability information? What will your downstream customers demand of you? Contracts first—documents can only follow.
6. Tighten access and key management: Vulnerability response presupposes knowing who can touch what. For governance of API keys and account permissions, see API key management and security best practices.
7. Bake security into procurement evaluation: For new system integrations and external service adoption, make compliance documentation capability a criterion from the vendor-selection stage. For integration-side practicalities, see the API integration practical guide.

Honestly, nothing on this list is something you should "wait until the regulation gets clearer" to do. Every item is fundamentals; the only difference is that doing it now is calm positioning, and doing it after September is incident response.

In our experience, the item enterprises stall on most is not a technical one—it is "designate an owner" in item 4. Engineering, legal, and sales each assume reporting is someone else's job, and when the deadline hits, three departments stare at each other. Pin down the person first; everything else starts moving after that.

Frequently Asked Questions (FAQ)

Here are the five questions Taiwanese enterprises ask most about the CRA. There is only one set of core facts: from September 11, 2026—24-hour early warning, 72-hour impact assessment, 14-day final report (TWCERT/CC, 2026).

Q: When do the CRA's vulnerability reporting obligations become mandatory?

A: According to the 2026 TWCERT/CC announcement, Article 14 vulnerability reporting obligations under the CRA become officially mandatory on September 11, 2026. From that day on, a manufacturer that discovers a vulnerability in its product being actively exploited must issue an early warning within 24 hours through the EU's single reporting platform (SRP).

Q: When does the CRA's 24-hour reporting clock start?

A: It starts when the manufacturer "discovers active exploitation" of the vulnerability: an early warning within 24 hours, a detailed vulnerability impact assessment within 72 hours, and a final report within 14 days of corrective measures becoming available; for significant incidents the final report deadline is extended to one month (TWCERT/CC, 2026).

Q: Our Taiwanese company has no EU presence—do we still have to comply with the CRA?

A: Yes, as long as your product enters the EU market. The CRA applies to all products with digital elements placed on the EU market and their manufacturers, and the test is product flow, not place of incorporation (TWCERT/CC, 2026). Taiwanese makers of connected hardware, firmware, and software are in scope whenever they export to the EU.

Q: Is an SBOM mandatory? Which format should we use?

A: In its 2026 announcement, TWCERT/CC described the SBOM as "the de facto hidden prerequisite" for CRA compliance in practice: without a component inventory, the 72-hour impact assessment is nearly impossible to produce. For format, the recommendation is the CycloneDX or SPDX international standards, which offer the best compatibility when exchanging documents across the supply chain.

Q: What is the maximum fine for violating the CRA?

A: Up to EUR 15 million or 2.5% of global annual revenue, whichever is higher (TWCERT/CC, 2026). Beyond the fine, the product may also face removal from the market, recall, or sales restrictions; for companies that depend on EU channels, the loss of market access is often more severe than the fine itself.

Conclusion: Treat September 11, 2026 as the Start of Your Compliance Countdown

The Article 14 enforcement date is locked in at September 11, 2026, and the deadline specs are fully public: 24 hours, 72 hours, 14 days (TWCERT/CC, 2026). Meanwhile, the Linux Foundation and OpenSSF survey tells us that 66% of practitioners are still unfamiliar with the act (iThome, 2026). In other words, companies that start preparing now begin the race ahead of most of their peers.

Where to start? Three steps.

Step one, inventory: confirm which products, software, and modules will enter the EU market, including your role in other companies' supply chains. Step two, SBOM: pick CycloneDX or SPDX and lay out your software components and external service dependencies as a single list. Step three, rehearse: designate a reporting owner and actually run the 24/72-hour workflow end to end.

Compliance was never a one-off project—it is a long-term effort that starts with asset inventory. But the starting point is clear: first see clearly what you have in hand.

---

🎯 Take Action Now

Turning your cloud and AI API procurement into an auditable supply chain is the fastest actionable step in CRA preparation. CloudInsight provides enterprise-grade cloud and AI API procurement agency services: formal contracts, government uniform invoices, and Chinese-language technical support, helping you complete the procurement side of your compliance paperwork in one pass.

👉 Consult now to get the plan that fits you best 👉 Join our official LINE account for real-time technical support

---

Further Reading

• API Key Management and Security | The Complete 2026 Guide to AI API Key Best Practices
• AI API Enterprise Procurement Guide | 2026 Reseller Selection, Discount Plans, and Compliance Workflows
• How to Get Invoices for AI APIs? The Complete 2026 Compliant Procurement Process for Taiwanese Enterprises
• How to Buy AI APIs in Taiwan? The Complete 2026 Purchase and Payment Tutorial (OpenAI, Claude, Gemini)
• What Is an Open API? The Complete 2026 Guide to Open APIs and the OpenAPI Specification

References

• EU CRA Article 14 vulnerability reporting obligations approaching mandatory enforcement — TWCERT/CC (2026)
• Linux Foundation Research and OpenSSF survey: 66% of software practitioners unfamiliar with the CRA — iThome (2026)