Three capabilities worth building 三個值得建立的能力

Part 2 closed on a question: capability that, once built, keeps running — that shape doesn’t match the compliance rhythm APAC manufacturers are most familiar with. This essay opens up that “doesn’t match” claim.

A useful recalibration sits inside this question. The first frame I worked with was that the CRA shifts compliance from “test once, get certified” to “continuous compliance” — a tempo change from one-off gate to ongoing function. That framing covers part of the picture, but a closer read reveals a deeper shift. The CRA isn’t only changing the frequency of compliance reporting. It’s changing who is doing the reporting. That second shift is what most APAC manufacturers haven’t fully sat with, and it’s worth a dedicated essay.

This essay does two things: first, get clear on where APAC manufacturers actually sit under their own national laws today; second, from that position, name three capabilities the CRA introduces that are worth building, and how to start building them.

§ 01Position check: who is the regulated party under APAC national laws today

Many APAC manufacturers, when planning CRA readiness, start with the intuition that “we already have a cybersecurity law, we already have incident reporting experience — the foundation isn’t bad.” That intuition is worth a recalibration — not because the experience is useless, but because the who of the existing experience is worth examining carefully.

Taiwan’s Cyber Security Management Act (CSMA) — promulgated 24 September 2025, in force from 1 December 2025. The reporting obligations apply to:

• Government agencies
• Specific non-government agencies: critical infrastructure providers, government-owned enterprises, designated foundations, and government-controlled entities or institutions

Japan’s Economic Security Promotion Act (ESPA) — published May 2022, with Reiwa 6 Law No. 28 of 17 May 2024 adding the port transport business. Regulates:

• Pre-deployment review of equipment introductions by 15 categories of specified social-infrastructure operators (electricity, gas, finance, telecommunications, port transport, etc.)

Japan’s Active Cyber Defence Law (ACDL) — formally the Act on Prevention of Damage from Unauthorised Activities Targeting Critical Computers (Reiwa 7 Law No. 42), passed by the Diet on 16 May 2025, promulgated 23 May 2025; most provisions are expected to enter into force during 2026, with provisions on communications-information use expected to apply from the second half of 2027. It regulates:

• Critical-infrastructure operators (基幹インフラ事業者): notification obligations for designated critical computers, plus reporting obligations on incidents (legally binding, with penalties)
• IT vendors and general enterprises: participation in public-private consultative bodies and information sharing (cooperation-based, not mandatory)

Korea’s Information and Communications Network Act (Network Act) — Article 48-3 (amended August 2024, with Enforcement Decree Article 58-2 entering into force at the same time) requires immediate incident reporting. The regulated parties are:

• Information and Communications Service Providers (ICSPs) — e-commerce, social platforms, portals, mobile banking, and other operators of network services
• The Article itself requires notification “without delay”; the specific 24-hour timeframe is set in Enforcement Decree Article 58-2
• Failure to report carries an administrative fine of up to KRW 30 million under Article 76
• An amendment passed in March 2026 (promulgated 31 March 2026) introduces a new Article 48-8 establishing a 3% revenue 과징금 (penalty surcharge) for repeat incidents, applying only when “two or more incidents occur within five years involving intent or gross negligence”, expected to enter into force in September 2026

Network Act Article 45 places obligations on IoT manufacturers and importers (the legal term is 정보통신망연결기기등, network-connected devices etc., with scope set by Enforcement Decree). But this Article is about pre-deployment protective measures (technical, physical, and managerial security controls) — not post-discovery vulnerability reporting.

Pulling these together reveals a common pattern: the reporting obligations under existing APAC national laws are placed primarily on operators — government agencies, critical infrastructure providers, ICSPs, critical-infrastructure operators. Manufacturers, unless they also occupy one of those operator roles, are not on the reporting-obligation list.

The cleanest way to verify this: a Taiwanese ODM specialising in IP cameras, IoT routers, or edge devices, as long as it isn’t itself on the CI-provider list (currently limited to entities like Taipower, CPC, Chunghwa Telecom, and similar government-linked operators), has no statutory reporting obligation under the current CSMA when its products are found to have vulnerabilities at the customer end.

CRA Article 14 is what changes this. The regulated party shifts from operator to manufacturer. From “if my own system has an incident, I report” to “if my product has a vulnerability, I report.” That’s a change in the regulated party itself, not a calibration of regulatory intensity.

§ 02Three capabilities worth building

With the position clear, three capability gaps come into focus. Each gap maps to a distinct dimension of CRA Article 14, and each dimension is one APAC manufacturers haven’t been trained for under existing national law.

Capability 1: statutory proactive reporting

CRA Article 14 requires the manufacturer, upon “becoming aware of” an actively exploited vulnerability in their product, to submit an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective measure becomes available.

The closest analogues across APAC are two:

Voluntary coordinated vulnerability disclosure platforms — TWCERT/CC TVN, JPCERT/CC’s Information Security Early Warning Partnership programme. The operating logic of these platforms is to receive reports from third-party researchers, coordinate disclosure to the affected vendor, and have the vendor work on remediation. From the manufacturer’s perspective, this is a passive-receive role — not an active push-to-government role.

Japan’s ACDL “cooperation requests” to IT vendors — but this is the government notifying the vendor of a vulnerability and the vendor responding with reasonable effort. The trigger is top-down, from government to vendor, not bottom-up from vendor self-discovery. For general IT vendors and enterprises, that part of the framework is cooperation-based and not mandatory (critical-infrastructure operators do face binding notification and reporting obligations with penalties under ACDL); overall the legal intensity sits in a different bracket from CRA’s mandatory proactive reporting backed by significant fines.

CRA Article 14 reverses the role. The manufacturer is the active party; the receivers are the government (through the ENISA Single Reporting Platform and Member State CSIRTs); the timelines are measured in hours; and breach exposes the manufacturer to fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher.

A useful starter posture: don’t try to stand up a 24/7 PSIRT from day one. Build a small “trigger-to-decision” workflow first — an external vulnerability intake (ISO/IEC 29147’s VDP framework is a useful reference), an internal 24-hour escalation SLA, and pre-designated authority on who can call “this needs to be reported.” Once a piece of information can move from intake through decision through external notification within 24 hours, the workflow exists. Headcount for a fuller PSIRT can be added incrementally.

Capability 2: post-market continuous monitoring and handling

CRA Article 13(8) requires the manufacturer to handle vulnerabilities continuously throughout the support period, which is not less than five years unless the expected use time is shorter. Article 14’s reporting obligations are the external output when something significant emerges from that ongoing handling. Combined, the two articles describe a complete post-market continuous monitoring and handling flow.

The compliance pattern APAC manufacturers know best is “pre-market type certification” — TAICS IoT marks, JC-STAR, KISA CIC, CNS 16120, BSMI registration. These are one-off pre-market conformity assessments; once the mark is granted, the product ships under it for the validity period (typically 2-3 years), and then the mark is renewed. The capability building in this pattern concentrates at the pre-market point; the post-market activity is renewal preparation, not continuous monitoring.

This pattern runs on a parallel track from the CRA’s post-market continuous-handling logic. The CRA doesn’t only require the product to be secure when it ships; it also requires, throughout the support period (in principle at least five years, unless the expected use time is shorter), that newly discovered vulnerabilities be addressed within specific time windows; that technical documentation be retained for at least 10 years or for the duration of the support period, whichever is longer; and that the whole sequence leave an auditable trail.

A useful starter posture: connect this directly to the Tier 1 work from Part 2. Three of the four Tier 1 principles map directly onto building this capability (4.18 Unique Device Identity is a pre-shipment secure-by-default control, in Tier 1 but not directly relevant to post-market continuous monitoring, so it sits aside here):

• 4.13 Vulnerability handling flow: issue tracker, severity classification, SLA, the patch-to-release linkage. Once this is operating, Article 14’s external reporting has an internal source.
• 4.14 SBOM: one per release, wired into vulnerability scanning. When a new CVE shows up in NVD or CISA KEV, you can determine within 24 hours which of your products and which versions are affected. That capacity is the single most strategic operational capability under the CRA.
• 4.20 Automated update mechanism: without a working update mechanism, Article 13 mostly doesn’t function. This has the highest build cost but also the highest cost of delay.

Once the three Tier 1 capabilities are running, the 24-hour reporting requirement has a working internal foundation. Without them, Article 14’s timelines tend to spin in place.

Capability 3: full product lifecycle obligation carrying

Three CRA articles, taken together, place the full product lifecycle inside the regulatory perimeter.

Article 13(8): the manufacturer handles vulnerabilities throughout the support period. The support period reflects the product’s expected use time and is not less than five years (unless the expected use time is shorter, in which case the support period equals that).

Article 13(13): technical documentation remains available to market surveillance authorities for at least 10 years from product placement on the market or for the duration of the support period — whichever is longer.

Article 69(3): by way of derogation from Article 69(2), the obligations laid down in Article 14 apply to all products in scope, even those placed on the market before 11 December 2027. In other words, pre-existing products generally don’t trigger CRA obligations (unless substantially modified), but the reporting obligation applies to them anyway.

Taken together, these three define a lifecycle envelope: from the start of design, through ten years after end-of-life, and including the reporting obligation for products already on the market before 11 December 2027 — that whole arc sits within CRA scope.

The obligation pattern APAC manufacturers know best is “within the type-certificate validity period.” The mark is valid for two to three years; renewal at expiry, or product end-of-life, ends the obligation. After end-of-life, the older product is typically out of scope for compliance work.

The CRA reshapes this envelope. End-of-life doesn’t mean end-of-obligation — vulnerabilities still need handling within the support period, and technical documentation still needs retention for at least 10 years or the support period, whichever is longer. For ODM operating models this shift carries particular weight, because the ODM-to-brand-customer relationship has typically been “project ends, obligation ends.” Under the CRA, what happens to ODM support responsibilities after a project closes is a question worth writing into the contract.

A useful starter posture: treat this as a contracting question, not only an engineering one. Specifics worth covering in the contract:

• Support period definition: how many years post-launch each side carries which CRA-driven obligations
• SBOM delivery: one per release, format (CycloneDX or SPDX), delivery cadence, update obligations
• Vulnerability information flow: SLA for two-way notification, contact points, confidentiality
• Security update responsibility: who develops, who signs, who delivers, how cost is shared
• End-of-life handling: post-EOL obligation allocation, including the final security update, customer notification, and assignment of the technical-documentation-retention obligation (at least 10 years or the support period, whichever is longer)

These are not items the ODM can settle unilaterally — they require the brand customer at the table to redesign the commercial relationship. This is also what makes 2026 a meaningful window to do the work. Full CRA application is 11 December 2027; redesigning the contract template through 2026 means new projects in 2027 can use the new template directly, which is more comfortable than redrafting under launch pressure.

§ 03The position difference, in one table

The table compresses Section II’s argument into one frame. The root of all three capability gaps sits on this table — different regulated party, different trigger, different time-scale, different scope.

§ 04Closing thought: this is an organisational topic, not only an engineering one

Returning to the question this essay opened with: why does “capability that, once built, keeps running” matter so specifically?

Because CRA Article 14 isn’t a one-off gate; it’s a continuous function. That function needs not only engineering capability but also matching organisational capability — a 24-hour escalation path, PSIRT ownership, contract clauses on the support period, and a two-way information flow with brand customers. These are organisation-level questions, not pure engineering hardening.

And the organisational capability has no ready training base in the APAC national-law world to build on. Limited experience isn’t an obstacle, but it’s worth acknowledging up front, so that resources and timelines are sized to the actual preparation work rather than to the surface impression of it.

Part 4 picks up the final thread: once the capability is in place, what it means for APAC manufacturers isn’t only “compliance, not fined” — it’s that an actual gap opens up between you and competitors on the EU market post-2027. SBOM, PSIRT, CVD, signed updates, an auditable support-period commitment — once these are in place, they aren’t only compliance cost; they become entry tickets to the EU market, and even bargaining leverage between an ODM and its brand customers. Compliance shifts from cost to capability — that argument is what Part 4 lays out.