Twenty-two principles, which four to run first 22 條原則、先跑哪四條

Part 1 framed the ENISA Playbook as a map, not a ticket. This essay starts unpacking the map.

The 22 principles look orderly when laid out side by side, but for an APAC SME manufacturer, the first question worth answering is not “how do we cover all of them” — it’s “which ones do we run first.” Resources are bounded, headcount is bounded, customer deadlines aren’t moving. Picking the order is itself a strategic decision.

This essay does three things: lay out a three-tier framework for sequencing the 22 principles by APAC SME operability; pick the four Tier 1 starters and explain why those four; and sketch Tier 2 and Tier 3 enough to show the full roadmap silhouette.

§ 01Why tier the principles instead of running all 22 in parallel

ENISA didn’t bake priority into the Playbook itself. That’s a reasonable design choice — their goal was a complete reference; the sequencing belongs to each adopting company. The catch is that without a sequencing pass, two failure modes tend to show up.

The first: starting from 4.1 and going in order, burning the budget by 4.5, leaving the remaining 17 stuck. The second: cherry-picking the principles already familiar to the team, then discovering at audit time that several CRA Annex I items aren’t covered. Neither outcome is great.

A useful sequencing frame uses three filters:

1. Does executing this principle stay inside the engineering org, or does it cross organisational boundaries? Self-contained principles run first.
2. How central is this principle to the Article 13/14 continuous obligations? Principles that directly cover Annex I Part II vulnerability handling get earlier slots.
3. What new capability does the minimum evidence require? Principles that build on incremental engineering capability come before ones that demand organisational restructuring.

Run the 22 principles through those three filters and they sort into three tiers:

• Tier 1 — four principles that can start immediately: don’t depend on the brand customer’s release decision, don’t require a complete CI/CD pipeline, can be initiated inside the ODM engineering org, and map directly to core Annex I Part II obligations.
• Tier 2 — about eight principles that need organisational translation: the principle itself fits the ODM, but execution requires designing the contract interface with the brand customer, an evidence-exchange mechanism, and a clear split of responsibilities.
• Tier 3 — roughly ten principles that wait for resources or external conditions: SDLC restructuring, PSIRT build-out, or principles that resolve cleanly only once harmonised standards mature.

§ 02The four Tier 1 starters: principles an ODM can run on its own

The four starters: 4.13 Vulnerability and patch management, 4.14 Supply chain controls, 4.18 Unique Device Identity and Secrets by Default, 4.20 Automated Maintenance and Updates.

What these four share: engineering responsibility lands clearly on the firmware-manufacturing side, the brand customer can neither do them for you nor stop you from doing them, and each one binds directly to a core Annex I Part II vulnerability-handling obligation or a Part I secure-by-default requirement.

4.13 Vulnerability and patch management

ENISA states the objective plainly: “Identify, prioritise, and remediate vulnerabilities fast enough to reduce real-world exposure, across your code, dependencies, infrastructure, and (if applicable) devices/firmware.”

The Annex I Part II coverage is dense — identification and recording (2.1), addressing without delay (2.2), public disclosure of fixed vulnerabilities (2.4), implementing a CVD policy (2.5), providing a reporting channel (2.6), secure release of updates (2.7), and delivering security updates without delay (2.8). One Playbook principle covers most of Part II.

Why an ODM can start this on its own: the vulnerability handling workflow, the CVD policy, and the secure update release process all live inside the engineering organisation. A brand customer may eventually require integration with their PSIRT process, but your internal flow is the precondition — without an internal flow, there’s nothing to integrate.

The minimum evidence shape: a vulnerability tracker (issue severity, affected component, owner, target date), an SLA definition (e.g. 48-hour triage for Critical, fix released within X days), CI dependency-scan results, an SBOM or dependency inventory per release, the patch-to-release linkage trail (ticket → PR → tests → release version → rollout confirmation), and an exceptions list (residual risks accepted, owner, expiry).

For most ODMs, that stack is reachable within 12 months at a “defensible to an external auditor” level — no need to throw existing process out and start over.

4.14 Supply chain controls

The core of this principle is the SBOM. CRA Annex I Part II point 2.1 requires manufacturers to “draw up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.”

The Playbook’s minimum evidence: a supplier and component inventory (primary vendors, key libraries and tools, hosting and build services), an SBOM (or dependency inventory) per release, CI dependency-scan results, signing of release artifacts, and basic supplier checks (security contact, vulnerability notification channel, support and patch commitment).

For ODMs, SBOM has tooling pathways that already exist — CycloneDX, SPDX, binary SBOM extraction tools (which work even when full source visibility isn’t available) all have mature commercial and open-source options. The work is making SBOM a regular product of the release pipeline, rather than a one-off document produced when a customer asks.

A second value sits behind this principle for ODMs: when your customer’s customers (the brand customer’s EU end-customers) start asking for SBOMs, you already have one. That readiness gap will start showing up directly in order flow after December 2027.

4.18 Unique Device Identity and Secrets by Default

This principle maps to Annex I Part I points 1.2.b (secure by default), 1.2.d (preventing unauthorised access), and 1.2.e (confidentiality).

ENISA’s core requirement: each device ships from the factory with its own keys and certificates, no shared default credentials, no hard-coded secrets, no shared keys baked into production builds.

This principle ties tightly into the ODM’s factory process — key injection, secure storage, designs that allow revocation and replacement. It looks like a production-line topic on the surface, but it’s actually a design-stage one: chipset selection (does it have a secure element, can it hold keys), boot flow (how to read, how to verify), first-boot flow (how to trigger unique credential generation).

Why this principle deserves an early slot: it’s the root-cause control for “shared default credential” failures, which underlie most of the publicly-exploited IoT incidents of the past decade. Annex I Part I 1.2.b names secure by default explicitly, and several downstream controls — the SBOM under Part II 2.1, the secure update under Part II 2.7 — assume the device has a trusted unique identity to anchor on. Without unique identity, several later controls sit on sand.

This principle looks more complex than the other three Tier 1 picks — chipset selection, boot flow, production-line key injection. That complexity is exactly why it makes sense to do early: the hardware and production line are the ODM’s home turf, places the brand customer rarely touches. Structurally, this obligation sits on the ODM side and isn’t easily passed through the contract chain. Building it early plants a competitive moat where it’s defensible.

The minimum evidence: per-device key issuance records, production data showing each device is unique, build artifacts confirming no hard-coded secrets, design documentation for how secrets are protected, and evidence of a working revocation mechanism.

4.20 Automated Maintenance and Updates

Maps to Annex I Part I 1.2.b (secure by default), 1.2.c (addressing vulnerabilities through updates), Part II 2.2 (timely remediation), and Part II 2.7 (secure release).

ENISA’s requirements are concrete: automatic security updates enabled by default, security updates deliverable separately from feature updates, cryptographic verification of updates, update failures that don’t leave the system insecure or unusable, and clear update-status communication to the user.

The challenge for ODMs is that the update infrastructure itself has to exist — signing key management, update server, client OTA mechanism, failure rollback. If none of that is in place yet, this is the highest-build-cost principle in Tier 1, but the value is high and the requirement is unavoidable.

The reason this principle sits in Tier 1 rather than Tier 2: the cost of delaying it is the highest. The whole architecture assumes a working update mechanism. Without one, Article 13 mostly doesn’t function. Tier 2 still leaves room for staged organisational translation; the update mechanism doesn’t.

§ 03A look at Tier 2: principles that need organisational translation

Tier 2 principles are sound on their own; their execution requires designing a cross-organisational interface. Two representative cases here, with Part 3 going deeper into the ODM-mode translation method.

4.1 Trust boundaries and threat modelling: threat modelling itself is something the ODM can run, but the outputs (critical assets, top threats, required mitigations) need to align with the brand customer’s product-level threat model. The work is designing a clear interface for “we cover this segment, you cover that segment.”

4.6 Open Design: this principle meets cultural friction in Asian engineering practice — firmware opacity has historically been treated as an additional protection layer. But the direction in CRA and ENISA is clear: security shouldn’t depend on the secrecy of the design; it should depend on protected keys, strong authentication, and well-tested implementation that holds under inspection. Translating this principle isn’t about how much source code to release — it’s about making sure the “auditable artifacts” exist: design documentation, API documentation, secure configuration guides, and CVD channels. For ODMs, this is a cultural transition more than a technical one.

Other Tier 2 candidates: 4.2 Least Privilege, 4.5 Defence in Depth, 4.7 Lifecycle Management, 4.10 Logging Monitoring Alerting, 4.11 Configuration & Change Management, 4.16 Restrictive Initial Access. Part 3 groups and discusses these.

§ 04A look at Tier 3: principles that wait for resources or external conditions

Tier 3 principles need SDLC-level restructuring or external-condition readiness. A few representative ones:

• 4.9 Secure coding practices: SAST/DAST integration into CI, PR review rules, CODEOWNERS. For many ODMs this is an SDLC-level engineering culture shift.
• 4.12 Incident response and recovery: 24/7 on-call, IR runbooks, tabletop exercises. Easier to extend incident response after the Tier 1 vulnerability handling under 4.13 is in place.
• 4.21 Transparent Security Posture / 4.22 Secure Recovery and Ownership Lifecycle: requires UX design participation, and B2B ODMs typically don’t own the customer interface — these benefit from collaboration with the brand customer’s design function.

These aren’t “skip” — they’re “later in the order.” With Tier 1 stable and Tier 2 organisational interfaces designed, Tier 3 gets pulled forward by the other conditions.

§ 05A 12-month sense of pace

A useful posture: don’t try to schedule all 22 principles at once. Use the first 90 days to inventory and start Tier 1, the following 6 to 9 months to bring the four Tier 1 principles to a “defensible to an external auditor” level, and the last 3 months to design Tier 2 contract interfaces with key brand customers. Tier 3 enters next year’s planning.

The key to this rhythm isn’t speed — it’s not breaking the chain. CRA Article 13/14 obligations are continuous compliance; capability that stalls 6 months in is effectively unbuilt. The reason Tier 1 sits in Tier 1 is precisely that once the capability is in place, it keeps running — you don’t start from zero with each new product launch.

Part 3 picks up the question this raises: why “capability that keeps running” is a different shape from the “test once, certify, ship until phase-out” rhythm APAC manufacturers tend to know best, and what organisational adjustments help the transition.