September 11: The Loophole Clock Starts Ticking — How the EU CRA's 24/72-Hour Rule Rewrites Taiwan's Hardware Exports

Article 14 of the CRA splits reporting into at least three checkpoints. The first is the early warning: without undue delay and no later than twenty-four hours after becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must submit it through the single reporting platform. The second checkpoint is the 72-hour notification: the company supplements more complete general information, a preliminary assessment, and any available mitigation measures. The third checkpoint is the final report: for a vulnerability, no later than fourteen days from the date a corrective measure becomes available; for a severe incident, no later than one month from the 72-hour notification. ^[1][2]

These three clocks serve different institutional purposes. The 24-hour clock lets the authority know that "a cross-market incident may be occurring"; the 72-hour clock lets the coordinating body form a preliminary judgment about scope and risk; only the final report requires a fuller account of cause, impact, and remedy or mitigation. The most common consequence of trying to merge the three into one polished report is not better quality — it is that the company misses the first statutory checkpoint while waiting for a forensic conclusion.

ENISA's FAQ of August 3 states plainly that the reporting process begins from the moment the manufacturer becomes "aware" of the incident. The platform's fields are deliberately layered: the 24-hour stage requires only minimal information — the type of notification, the manufacturer, the product, and a title; the 72-hour stage requires a general description of the vulnerability or incident, a preliminary assessment, and measures taken; the final stage requires the complete content. ^[4][5] This design acknowledges that a security incident is inevitably incomplete at the outset, but it does not accept total silence from a company simply because information is incomplete.

For a Taiwanese company, the first governance question is not "how long will engineers need to finish the fix," but "at what moment does the organization count as having known." A credible report of in-the-wild exploitation reaching customer service, an SOC observing malicious traffic, an open-source component maintainer announcing an attack, or a reproduction case forwarded by a brand customer from its own researchers — these signals can land in different legal entities and systems at different times. The regulation does not draw an internal accountability map for every multinational group. Without a pre-defined path for incident intake, credibility escalation, and legal notification, a company will spend its actual twenty-four hours arguing about who knew first.

The most conservative and workable approach, therefore, is to log the first credible signal as an internal T0: preserve the original message, time zone, recipient, product, and initial rationale; the technical team can keep verifying, but it must not overwrite the original timestamp. T0 does not automatically equal "awareness" under the CRA, nor does it automatically mean a report is required — it merely gives subsequent judgment an auditable starting point. Whether the statutory threshold has actually been met is still a determination the legal manufacturer must make based on the facts and legal advice.

Companies tend to make two opposite mistakes. One is to trigger the 24-hour statutory report for any CVE at all, generating enormous noise; the other is to assume that because a vulnerability sits in a third-party component, or because it has not yet confirmed a customer was hit, it can do nothing. The CRA's threshold sits between the two.

An "actively exploited vulnerability" is not simply the existence of a weakness, nor a high severity score — it is reliable evidence that a malicious actor has already exploited it without authorization. ^[1] A vulnerability-scan hit, a proof-of-concept published by a researcher, a vendor patch release, and observed malicious exploitation are all different evidentiary states. Engineering remediation may need to start for all of them, but the CRA's mandatory-reporting determination cannot substitute a severity score for evidence of "active exploitation."

A severe incident is a separate track. The regulation is concerned with whether an incident has had or may have a significant impact on a product's ability to protect the data and functions it processes, stores, or transmits, and whether it has led or may lead to malicious code being introduced into the product or a user's system. ^[1][4] In other words, the absence of a publicly disclosed CVE does not mean an incident cannot meet the threshold; conversely, a high-scoring CVE does not necessarily mean a severe incident has already occurred.

Taiwanese suppliers are best served by splitting their internal incident log into two columns. The first records technical status: whether the vulnerability exists, is reproducible, has been exploited, which products and versions are affected, and what mitigation is currently in place. The second records legal status: which type of CRA event is suspected, whether the evidence meets the threshold, who made that determination, and when it will be reassessed. The two columns share the same incident ID, but neither can substitute for the other. This way, the company neither stops blocking malicious traffic while waiting for a legal opinion to be finalized, nor mistakenly claims a statutory report has been completed just because engineering issued an urgent patch.

The CRA places its obligations on the "manufacturer," but in industry parlance "manufacturer" often means whoever actually produced or assembled the device. The two are not the same concept. Under the EU regime, what determines legal status is the name or trademark under which a product is placed on the market, and who controls its design and compliance. An importer or distributor may also take on manufacturer obligations if it supplies a product under its own name or trademark, or makes a substantial modification to it. ^[1][10]

The same piece of networking equipment can therefore sit in one of three scenarios. First, a Taiwanese own-brand company exports directly to the EU: the Taiwanese company may itself be the non-EU manufacturer, fulfilling its EU obligations through arrangements such as an authorized representative or importer. Second, a Taiwanese ODM produces to a European brand's specification and the product is placed on the market under that brand's trademark: the European brand is more likely to be the legal manufacturer, and the Taiwanese factory is a critical source of information. Third, an EU importer rebrands or substantially modifies the product: its legal role may be upgraded accordingly. The reporting responsibility, the coordinating CSIRT, and the data-handoff path differ in each scenario — no single generic workflow can cover all three.

Article 14 of the CRA also sets out how the coordinating CSIRT is determined. In principle, it looks to the manufacturer's main place of establishment — that is, where the product's security decisions are primarily made; if the manufacturer is not established in the EU, the order falls to the authorized representative, then the importer, then the distributor, and ultimately the member state where the product's users are located. ^[1][4] This is not merely an administrative field for a company registration address — it concerns who controls a product's security decisions and which EU node bears the obligation.

The most valuable thing a Taiwanese company can do now is not to ask "are we the manufacturer" once and be done with it, but to map a legal-role table line by line, by product: the market name, the trademark owner, who holds the right to change the design, who controls software updates, the EU authorized representative, the importer, the primary markets, and the person who decides whether to report. If the answers are scattered across sales, legal, and project-manager inboxes, no one will be able to determine the legal role within a few hours when an actual incident occurs.

The CRA does not explicitly require a Taiwanese ODM to report to its brand customer within four hours. However, if a brand owner must complete incident triage, internal approval, translation, and SRP submission within the statutory twenty-four hours, it cannot possibly leave the entire twenty-four hours to its upstream supplier. It is therefore a highly predictable commercial inference — not a confirmed regulatory fact — that brand procurement contracts will compress the supplier notification window to four, eight, or twelve hours.

This "clock compression" redistributes cost. In the past, post-sale security work ran on business days, patch cycles, and complaint priority; now it requires round-the-clock contacts, cross-time-zone escalation paths, log retention, product-version lookup, third-party component contacts, and confidential legal channels. A large ODM may be able to stand up a 24-hour PSIRT, but small module makers, firmware contractors, and open-source component suppliers may not have equivalent resources. If a brand owner only writes an extremely short deadline into a contract without jointly defining the data format, severity, test environment, and cost allocation, the supply chain may end up delivering more incomplete alerts rather than faster, reliable evidence.

A reasonable contract annex should at minimum answer: which events require immediate notification? Who is authorized to receive them on each side? What backup exists for holidays and staff turnover? What is the minimum content of the first data package? What encrypted channel is used to transmit sensitive exploitation information? If a third-party component affects multiple brands at once, who coordinates? How are the costs of remediation, external forensics, and emergency testing shared? Without answering these questions, simply shortening the deadline will only shift liability rather than build capability.

A digital product is usually not the work of a single company. Chip SDKs, open-source libraries, wireless modules, cloud agents, mobile apps, and update services may all be maintained by different teams. When a shared component is actively exploited, the brand owner must know which products, which firmware, and which EU markets are actually affected; the Taiwanese integrator, meanwhile, needs to work backward from a component version to the customer's model numbers.

If a company has only a purchasing part number and no software bill of materials or record of the version actually shipped, three kinds of delay follow: time spent confirming whether the component was even used, time spent identifying which versions have already been updated, and, only then, time spent finding the right brand contact. This work used to be handled leisurely within a patch cycle; now it eats directly into the statutory clock.

A usable product-component ledger does not need to be perfect from day one. At minimum it should include the product's commercial name, internal part number, firmware version, key third-party components and their versions, the person responsible for maintenance, the end-of-support date, the EU member states of sale, and the legal manufacturer. When an external report contains only a component name and indicators of attack, the team can work backward within hours to identify possibly affected products, then narrow the scope — rather than starting from zero and querying every project individually.

ENISA's FAQ notes that whether an exploited vulnerability in a third-party component requires every integrating manufacturer to report still depends on the specific determination in the Commission's implementation FAQ. ^[4][9] This is a reminder that companies should not treat an upstream report as their own proof of exemption, nor mechanically re-submit reports without analyzing the impact on their own product. Shared components require shared technical facts, but each legal manufacturer must still make its own determination about its product and market obligations.

Companies' worry that sending unpatched vulnerabilities into a cross-national platform will spread the information is not unfounded. The CRA's design has a single platform sending data simultaneously to the coordinating CSIRT and ENISA, which the coordinating CSIRT then forwards to the relevant CSIRTs and, where necessary, market surveillance authorities in the member states where the product is placed on the market. ^[1][2][4] The distribution scope can be sizeable, so data quality and sensitivity labeling must be handled with care.

On the other hand, this is not an automatic post to a public vulnerability database. The regulation requires authorities to protect confidentiality, trade secrets, and security-sensitive information; the system also provides for delaying or restricting distribution in special circumstances where immediate distribution would create greater security risk. ^[1][4] ENISA may, after a patch is available, later bring vulnerability information into the European vulnerability database — a separate, later stage from the controlled handling of the 24-hour early warning.

The correct approach is neither to cram every technical detail into the first submission, nor to leave no paper trail out of fear of leaks. The 24-hour data package should contain only the minimum information needed to identify the incident and the product, clearly flagging what remains unconfirmed, what is sensitive, and what immediate mitigation is in place; details such as the exploitation chain, keys, or customer identifiers should be graded and submitted according to the platform's fields and legal judgment. Internally, companies should also restrict access to raw evidence and keep a record of who viewed it, who downloaded it, and who approved its transmission.

A Taiwanese company can operationalize the system with four coordinated ledgers.

The first is the "legal role ledger." It answers, for every product, under which name and trademark it is placed on the EU market, who is likely the CRA manufacturer, the contact point for the coordinating CSIRT, and who has the authority to submit. The second is the "product-component ledger," linking product, firmware, component, version, support period, and member states of sale. The third is the "incident-clock ledger," preserving the original T0, every escalation, decision, and outbound transmission with a timestamp. The fourth is the "reporting-decision ledger," setting out the evidence supporting a determination of active exploitation or severe incident, what remains unknown, who made the legal judgment, and when it will next be reassessed.

All four ledgers must share the same incident ID. Otherwise, the SOC's alert, engineering's Jira ticket, the brand customer's email, and legal's opinion become four cases that do not recognize one another. Incident status should also be more than a binary "reported / not reported" — it can use states such as "under observation, technically confirming, suspected to meet threshold, decided to report, decided not to report pending reassessment, 24-hour submission sent, 72-hour supplement sent, final report complete." Each state should have an owner and a next deadline.

A minimally usable 24-hour package should be able to answer: who received what credible signal, and when; which product and version may be involved; why active exploitation or a severe incident is suspected; which EU markets the product is sold in; what blocking, feature disabling, or customer mitigation is currently in place; what remains unknown; and when the next update will come. This information is not the final truth, but it is enough to let the legal manufacturer hold the first checkpoint.

The 72-hour package then adds a more stable general description of the vulnerability or incident, the attack or exploitation method, preliminary impact, affected versions, and measures already taken and available to users. Only the final report needs to fully account for severity, impact, root cause, and remedy. Every update should preserve the differences between versions rather than overwriting an earlier conclusion with a new one — otherwise there is no way to explain afterward why a particular decision was made at the time. ^[4][5]

The first scenario: a researcher notifies a Taiwanese ODM that a firmware component has an exploitable attack, but no in-the-wild exploitation has been observed yet. Here, engineering remediation and brand notification can begin, but the company cannot conclude that a mandatory CRA report has been triggered simply because a proof of concept exists. Log the evidence, confirm the product, monitor for exploitation signals, and set the legal status to "pending reassessment."

The second scenario: a brand customer forwards a credible record of malicious exploitation involving models already sold in Germany and France. Here, the internal T0, the product-component lookup, evidence preservation, and legal escalation should all start simultaneously. Even before the root cause is known, the legal manufacturer should be assessing the 24-hour early warning; the ODM should not wait until a patch is complete before responding.

The third scenario: a cloud-service incident causes multiple devices to lose authentication capability, but no vulnerability exploitation has been confirmed. The team cannot rule out the CRA simply because "there is no CVE" — it must separately check the severe-incident criteria for availability, authenticity, integrity, confidentiality, and the risk of malicious code. This is exactly why the two reporting pathways must be kept separate.

When running a drill, do not tell participants the full answer in advance. Let customer service receive an ambiguous message first, have engineering obtain the logs later, and put brand legal in a different time zone, then observe four things: how long it takes to establish a shared incident ID, how long it takes to identify the legal manufacturer, how long it takes to produce the minimum data package, and who has the authority to decide whether to submit. When a drill fails, it is usually not because engineers are too slow — it is because the contact list, the authority, and the data relationships simply do not exist.

The closer the effective date gets, the less time should be spent on an overly grand compliance deck. In the first week, take stock of products exported to the EU and their legal roles, confirming the brand, the authorized representative, the importer, and the emergency contact. In the second week, build a minimum product-component table and a T0 form, and run a tabletop exercise on the most common product line. In the third week, fill in supplier contracts, confidential transmission channels, and holiday on-call coverage, and prepare the basic account requirements such as an EU Login.

As of August 3, ENISA states that the dedicated public URL for the SRP will be published before it goes live, and that no API is currently available; verification of representative status is handled by the coordinating CSIRT, and initial verification should not obstruct submission. ^[4][6][7] Companies can therefore prepare accounts, proof of representation, and field data in advance, but they cannot assume platform integration is already complete. Brands with high automation needs should also keep a manual-submission and dual-review fallback in reserve.

The fact that most of the CRA's main product obligations do not fully apply until December 11, 2027 does not mean 2026 reporting is merely a dress rehearsal. ^[1][2] Article 14 is already an independent statutory obligation; violations of core provisions such as Articles 13 and 14 can generally draw an administrative fine of up to fifteen million euros or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. ^[1] However, the regulation separately provides that micro and small enterprises that fail to submit the Article 14 early warning within twenty-four hours are not subject to this administrative fine — this does not exempt them from the underlying reporting obligation or from liability for other violations. ^[1] Companies should certainly not govern themselves purely for fear of fines, but the penalty regime shows that the EU treats reporting capability as a product-market responsibility, not an optional customer-service extra.

As of August 24, 2026, at least three things should not be treated as settled. First, the official SRP portal and the complete list of coordinating CSIRTs have yet to be published; ENISA's own documentation will keep being updated. ^[3][4] Second, which node within a multinational group's information reaches the level of manufacturer "awareness" depends on the organization's design and the specific facts — this article cannot render a legal conclusion for any individual case. Third, how much time, cost, and liability a brand owner will pass on to its suppliers depends on contract negotiation, not on anything the CRA automatically dictates.

Real maturity in preparation, then, is not pretending every unknown has been answered — it is giving every unknown an owner, a next review time, and an interim response. An incident can be labeled "product scope unknown," but someone must be designated to check the product ledger within two hours. It can be labeled "active exploitation unconfirmed," but someone must be designated to gather evidence from researchers and threat-intelligence sources. It can be labeled "legal manufacturer to be confirmed," but all possibly responsible parties must be notified first — the clock cannot be allowed to disappear in the gaps between organizations.

The CRA's twenty-four hours does not simply push the security team to move faster. It compresses knowledge that used to be scattered across after-sales service, legal, brand, and contract-manufacturing systems into a single auditable timeline. For Taiwan's supply chain, the most valuable capability is therefore not only patching faster, but being able to say three things accurately when information is incomplete, responsibility spans multiple legal entities, and the vulnerability is still sensitive: what is known right now, why that judgment was made, and who owns the next deadline.

What truly starts running on September 11 is the organization's own clock. If the product inventory, the role table, the confidential channels, and the decision records do not exist today, buying a new platform after an incident occurs will not buy back the twenty-four hours that have already been lost.