Design for Security
Design for Security applies the Design for Excellence philosophy to a product's resistance to attack. Like manufacturability, testability, and reliability, security is a lifecycle property that a product either possesses by construction or does not possess at all. It cannot be inspected into a finished design, and once the silicon, the enclosure, the test flow, and the key management infrastructure have been committed, a later firmware release can only work within the boundaries those decisions fixed. The discipline therefore concerns process and sequencing as much as technology: who decides what must be protected, at which design review, against which adversary, and at what cost to the other DFX objectives.
This article treats security as a design methodology and a set of engineering trade-offs. It does not restate the mechanisms themselves. Threat modeling technique, formal verification, hardware Trojan detection, side-channel countermeasures, secure boot chains, and cryptographic module internals are covered in depth elsewhere on this site and are linked at the end. The concern here is how a development organization converts a threat picture into requirements, budgets those requirements against area, cost, test time, and schedule, and carries them through manufacturing, field service, and disposal without leaving a gap that an attacker can occupy.
Security as a Design Constraint
Why Late Security Fails
The cost of a security decision rises steeply with the phase in which it is made, and for hardware the curve is harsher than for software. A decision to include a hardware root of trust costs silicon area at architecture time, a mask revision at tape-out, and a product recall after launch. Some decisions become simply unavailable: a microcontroller whose boot ROM verifies images with a fixed algorithm cannot be migrated to a different algorithm in the field, and a package with no provision for a tamper mesh cannot acquire one after the tooling is cut. Security work that begins at the end of development can only add detection and mitigation on top of an architecture that has already fixed the attacker's opportunities.
The practical consequence is that security requirements must enter the process alongside functional requirements, at the same review gates, with the same traceability. Mature organizations treat an unresolved security requirement exactly as they treat an unresolved thermal or timing requirement: as a condition that blocks the gate. The secure development lifecycle standards described below exist largely to make that discipline auditable by a third party.
Assets, Adversaries, and Sufficiency
Security requirements are meaningless without a stated adversary. "Secure" is not a property of a device; resistance to a defined attacker with defined resources is. Design for Security therefore begins with two inventories. The first lists the assets: cryptographic keys, firmware and the intellectual property it embodies, user data, calibration constants, production entitlements, and the integrity of the device's own behavior when it controls something physical. The second lists the adversaries, ranked by capability, motivation, and access.
The distinction that most shapes hardware design is between an adversary who reaches the device only through its network interfaces and one who holds the device in hand. Remote attackers are constrained to protocol and software flaws. Local attackers can measure power consumption and electromagnetic emissions, inject faults with voltage glitches or lasers, probe internal buses, and decapsulate packages. A product that will sit in a locked equipment room faces a different profile from a consumer device sold at retail, a utility meter mounted on the outside of a building, or a payment terminal whose owner may be the attacker.
Sufficiency is expressed in terms of attack potential rather than absolute protection. Evaluation methodologies quantify an attack by five separate factors: the elapsed time it requires, the expertise it demands, the knowledge of the target it presumes, the window of opportunity it needs, and the equipment it consumes. The Joint Interpretation Library tables used for smart card evaluation assign points to each factor and sum them into a single attack potential rating, which in turn fixes the vulnerability analysis component, AVA_VAN, that a Common Criteria evaluation can claim. The design goal is not to make an attack impossible but to raise its cost above the value of the asset for the duration of the product's life, which is why an unattended asset worth a few dollars and a national-security asset worth pursuing for years yield very different designs.
Deriving and Allocating Requirements
Risk Assessment
Structured threat analysis converts the asset and adversary inventories into a ranked list of risks. STRIDE categories, attack trees, and the threat analysis and risk assessment (TARA) method specified by ISO/SAE 21434 for road vehicles all serve this purpose, and the choice among them matters less than performing one consistently and recording the result. The distinction between a standard and a mandate is worth keeping straight: ISO/SAE 21434 describes how to do the work, while the legal obligation for vehicles comes from UN Regulation No. 155, which treats conformance to the standard as an accepted way of discharging it. The output that the rest of the process consumes is a set of risks with an assessed impact and an assessed feasibility, each traced to the asset it endangers.
Two failure modes recur. The first is analyzing the product in isolation, ignoring the provisioning equipment, the update server, the signing infrastructure, and the returns process, which are frequently the softest targets. The second is treating the analysis as a one-time deliverable. A threat model is a living document; a new interface, a new supplier, or a published attack against a chosen primitive invalidates parts of it, and the review cadence must be defined at the outset.
From Risk to Testable Requirement
Each accepted risk yields a countermeasure, and each countermeasure must be allocated to a specific owner: a hardware block, a firmware component, a manufacturing procedure, or an operational commitment. Allocation is where security requirements become budget items. A requirement for authenticated boot allocates ROM space, one-time-programmable fuses for the root key hash, and boot latency. A requirement for side-channel resistance allocates silicon area for masked datapaths and, often, a substantial fraction of the verification schedule. A requirement for unique device identity allocates seconds of automated test equipment time per unit, which at high volume is a real capital expense.
Requirements that cannot be verified should not be written. "The device shall resist tampering" gives the verification team nothing; "the enclosure shall detect opening within 50 milliseconds, including when main power is absent, shall erase the key store on detection, and shall record the event for reporting at the next power-up" can be tested, costed, and argued about at a design review. Writing requirements in testable form also exposes early which claims the organization intends to certify and which it merely intends to assert.
Architectural Choices That Set the Ceiling
Selecting a Root of Trust
Nearly every security property of a device chains back to a root of trust: an immutable starting point whose integrity is assumed rather than verified. Choosing its form is the single most consequential Design for Security decision, and it is made early, when the least is known.
An integrated root of trust places the boot ROM, key storage, and cryptographic accelerators on the main die, often behind an isolation mechanism such as Arm TrustZone. It adds no bill-of-materials cost and exposes no inter-chip bus to probing, but it consumes die area and a substantial share of the design and verification effort. A discrete secure element or a Trusted Platform Module conforming to ISO/IEC 11889 places those functions in a purpose-built package that is typically hardened against invasive and side-channel attack and that may carry its own independent certification. The discrete approach adds component cost and board area, and it creates a bus between the host and the secure device that itself must be authenticated, because an attacker who can rewrite the messages crossing that bus can often bypass the protection the part provides.
The decision interacts with volume, certification strategy, and organizational competence. A team without cryptographic hardware expertise generally obtains stronger security from a certified secure element than from an in-house implementation, even though the integrated option looks cheaper on the bill of materials.
Partitioning and Attack Surface
Attack surface is a design output, not an accident. Every external connector, radio, debug header, expansion bus, and diagnostic command is an entry point that must either be defended or removed, and removal is almost always cheaper. Reduction begins with a written inventory of interfaces and, for each one, an explicit decision about who may use it, in which lifecycle state, and after what authentication.
Within the device, partitioning limits the reach of a successful compromise. Separating security-critical functions into a small, auditable domain with a narrow, well-defined interface bounds the code that must be trusted, which in turn bounds the cost of the verification and certification that security requirements impose. Coarse partitioning has the opposite effect: when every function shares the memory map, the entire firmware image becomes security-relevant, and the assurance work scales with the whole product rather than with its critical core.
Designing for the Factory
Identity and Key Provisioning
A device that leaves the factory without a unique, unforgeable identity cannot later be authenticated, individually revoked, or trusted to authenticate anything else. Provisioning that identity is a manufacturing operation, and it must be designed into the test flow rather than improvised on the production floor.
Two patterns dominate. In the first, a hardware security module on the test floor generates a key pair and a certificate and injects them through the tester. The infrastructure is well understood, but the private key exists outside the device, so the manufacturing site becomes a high-value target and the contract manufacturer must be trusted accordingly. In the second, the device generates its own key pair internally, using an on-chip random number generator or a physical unclonable function, and emits only a certificate signing request; the private key never leaves the die. This pattern removes the factory from the trust boundary at the cost of requiring qualified entropy on the device and a functioning certificate authority in the production line. IEEE 802.1AR gives these credentials a standard form: an initial device identifier (IDevID) installed by the manufacturer and intended to last the life of the device, and locally significant device identifiers (LDevIDs) that an operator issues once the device joins a particular network. For parts too constrained to carry a full certificate hierarchy, the Trusted Computing Group's Device Identifier Composition Engine derives identity and attestation keys from a unique device secret combined with a measurement of the firmware, so that the identity a device can prove changes whenever its firmware changes.
Provisioning also imposes concrete Design for Manufacturability constraints: per-unit test time, secure network connectivity to the production line, key ceremony and audit procedures, and a documented response for the case in which a signing key is compromised. Deciding at the requirements stage that a single symmetric key shared across the entire fleet is unacceptable is inexpensive; discovering it after ten million units have shipped is not.
Lifecycle States and Production Control
Modern secure devices implement an explicit lifecycle state machine, typically progressing from blank, through test and provisioning, to a secured deployed state, with a defined path for authorized returns. Progression is enforced by hardware, usually by one-time-programmable fuses, so the sequence ratchets forward and cannot be quietly wound back in the field. The design work is in deciding which capabilities each state exposes: what a tester may do, what a provisioning station may do, what remains available after the part is secured, and what a returns facility may recover. Where a transition toward a more permissive state is offered at all, the rule that makes it safe is that the hardware erases every secret before that transition completes, so a return path cannot become an extraction path.
The same mechanisms address unauthorized production. A contract manufacturer with the full design and unlimited activation capability can build overruns that are indistinguishable from authentic units. Requiring each unit to receive a limited, individually accounted activation credential before it becomes functional converts overproduction from a manufacturing decision into a cryptographic problem, and it gives the brand owner an auditable count of legitimate devices.
Trade-Offs Against the Other DFX Disciplines
Testability
Design for Testability and Design for Security pull in opposite directions with unusual clarity. Testability seeks controllability and observability of internal state; scan chains grant exactly that over every flip-flop on a die, and boundary scan under IEEE 1149.1 grants it at the board level. An attacker who can shift out the scan chain of a cryptographic core after a single round of operation has been handed the internal state that the entire design exists to hide.
Resolving the conflict requires an explicit joint decision rather than a unilateral one by either team. Common resolutions include excluding security-critical registers from the externally accessible scan chain and testing those blocks with built-in self-test instead; forcing a reset of all secret-holding state on entry to or exit from test mode; permanently disabling external test access by fuse as part of the transition to the secured lifecycle state; and gating any post-production debug behind a challenge-response unlock bound to the individual device's identity, so that authorized field diagnosis remains possible while a generic unlock does not exist. Each option costs test coverage, diagnostic capability, or area, and the cost belongs in the requirements discussion, not in a late escalation.
Cost, Serviceability, and Sustainability
Against Design for Cost, security competes for die area, bill-of-materials value, test seconds, and engineering months. The recurring costs are frequently underestimated: maintaining a code signing infrastructure, staffing a product security incident response function, and shipping updates for the whole supported life of the product are operating expenses that begin at launch and end only at obsolescence. Regulation increasingly fixes that horizon rather than leaving it to the manufacturer, so the support period should be treated as a costed design input.
Against Design for Serviceability and Design for Environment, the conflicts are equally direct. Potting compound and tamper-responding meshes defeat repair as effectively as they defeat probing. Cryptographic pairing between a component and a system prevents an attacker from substituting a malicious module and simultaneously prevents an independent repair shop from fitting a genuine replacement part, an outcome that now attracts regulatory attention in several markets. Anti-tamper seals that void a warranty on opening discourage the disassembly that recycling depends on. These are genuine value conflicts, not oversights, and they are best resolved deliberately: protect the small subset of components that actually holds secrets, and leave the remainder serviceable.
Designing for the Field and for End of Life
Update Capability and Cryptographic Agility
The ability to deliver an authenticated firmware update is the most valuable single security feature in most products, because it is the only one that addresses vulnerabilities not yet known at design time. Designing it in means reserving flash for a second image or a staging area, reserving fuses or a monotonic counter for rollback protection, sizing the power budget for an interrupted update, and guaranteeing that a failed update leaves a recoverable device. A product whose memory map has no room for a second image has effectively decided never to be patched.
Long-lived hardware needs cryptographic agility for the same reason. Algorithms weaken. The National Institute of Standards and Technology published its first post-quantum standards in August 2024: FIPS 203 for the ML-KEM key encapsulation mechanism, FIPS 204 for the ML-DSA signature scheme, and FIPS 205 for the hash-based SLH-DSA signature scheme. A second key encapsulation mechanism, HQC, was selected in 2025 for standardization as a backup resting on different mathematics. These are successors to RSA and elliptic-curve cryptography rather than optional additions: NIST's draft transition guidance, IR 8547, proposes deprecating the classical public-key schemes after 2030 and disallowing them after 2035, a horizon well inside the service life of much industrial and infrastructure equipment.
The design consequence is dimensional. A boot ROM whose signature buffer was sized for the sixty-four bytes of an ECDSA P-256 signature has no room for a lattice-based signature measured in kilobytes, and hash-based signatures are larger still. Verification time, one-time-programmable storage for root key material, and update image size all grow with the change. Equipment designed today for a twenty-year service life should therefore either support algorithm negotiation, so that the verification routine is not welded to one primitive, or at minimum reserve the storage and performance margin that a transition will consume. Hardware that can do neither has fixed its cryptography permanently, which is the same defect as shipping without an update path.
Decommissioning
End of life is part of the design. A device that reaches a recycler with its keys, credentials, and stored data intact becomes a source of both fleet secrets and personal information. The countermeasures are inexpensive when planned: a documented and verifiable erase procedure, key storage that supports cryptographic erasure so that destroying a single wrapping key renders the remaining data unreadable, and a decommissioning path that revokes the device's identity in the back-end infrastructure rather than leaving a valid credential in circulation.
Process Standards, Evaluation, and Regulation
Secure Development Lifecycle Standards
Several standards codify the process this article describes, and conformance to one of them is increasingly a condition of sale. IEC 62443-4-1, written for industrial automation and control products, defines eight practices spanning security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines, and it assesses each against four maturity levels. ISO/SAE 21434 imposes a comparable structure on road vehicle development, with risk assessment and a cybersecurity case carried through the supply chain. IEC 81001-5-1 serves the same role for health software and medical device software, and NIST Special Publication 800-218, the Secure Software Development Framework, provides a sector-neutral formulation. The technical baselines that accompany them, including IEC 62443-4-2 for control system components, ETSI EN 303 645 for consumer Internet of Things devices, and NIST IR 8259A, define what the resulting product must actually do.
Evaluation and Certification
Third-party evaluation converts internal claims into evidence a customer can rely on. Common Criteria, standardized as ISO/IEC 15408, evaluates a product against a security target at assurance levels EAL1 through EAL7 and remains the reference regime for smart cards and high-assurance equipment. Two qualifications belong in the architecture decision rather than in a later compliance review. The first is that international mutual recognition under the Common Criteria Recognition Arrangement covers evaluations against agreed collaborative protection profiles and the lower assurance levels, so a certificate at a high assurance level is not automatically honored in every market that recognizes the scheme. The second is regional: in the European Union, Commission Implementing Regulation (EU) 2024/482 established the EUCC scheme, applicable since 27 February 2025, which carries the former SOG-IS mutual recognition arrangement into the certification framework of the Cybersecurity Act.
FIPS 140-3, which adopts ISO/IEC 19790, validates cryptographic modules at four security levels and is required for modules that protect sensitive information in United States and Canadian federal systems. Its transition is itself a schedule risk worth tracking, because the Cryptographic Module Validation Program stopped accepting new FIPS 140-2 submissions in September 2021 and the remaining FIPS 140-2 certificates move to the historical list on 21 September 2026; a product that still rests on one has no current validation after that date. Lighter-weight schemes have emerged for connected products whose margins cannot absorb a full Common Criteria evaluation, including SESIP, published in Europe as EN 17927:2023, and the industry-run PSA Certified program. Both are built around reuse: a platform certified once carries part of the assurance argument for every product built on it, which turns the choice of silicon and operating system into a certification decision as well as a technical one.
Certification is a schedule item and a cost center, not a formality. Laboratory queues, evidence preparation, and the rework that findings generate are measured in months, and any design change after evaluation may require maintenance of the certificate. Products that intend to certify should select the scheme and the protection profile before the architecture is frozen, because the scheme dictates what the evidence must show.
Regulatory Deadlines as Design Inputs
Regulation has moved security from a competitive differentiator to a market access condition, and each instrument carries a date that belongs in the product schedule. In the European Union, the first binding requirement is already in force. Delegated Regulation (EU) 2022/30 activated the cybersecurity provisions of the Radio Equipment Directive, Article 3(3), points (d), (e), and (f), from 1 August 2025, after a twelve-month postponement, so radio equipment in scope must protect the network it attaches to, safeguard personal data, and guard against fraud in order to carry a CE mark. The harmonized standards EN 18031-1, EN 18031-2, and EN 18031-3 offer a presumption of conformity, but the Commission cited them with restrictions in Implementing Decision (EU) 2025/138, so the presumption does not extend to every clause and the remaining gaps have to be closed by other evidence.
The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024; its vulnerability reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027. It requires manufacturers of products with digital elements to perform risk assessment, ship without known exploitable vulnerabilities, provide security updates across a support period that reflects the product's expected lifetime, and document components in a machine-readable software bill of materials, for which SPDX and CycloneDX are the formats in general use. In the United Kingdom, the Product Security and Telecommunications Infrastructure regime took effect on 29 April 2024, prohibiting universal default passwords and requiring both a vulnerability disclosure contact and publication of the minimum period for which security updates will be supplied. For road vehicles, UN Regulations No. 155 and No. 156 tie type approval to an audited cybersecurity management system and software update management system. Each of these translates directly into design and process requirements, and each has a date attached, which makes the regulatory calendar an input to the product plan rather than a compliance activity at the end of it.
Common Pitfalls
A small number of failures account for a large share of field compromises, and every one of them is a design decision rather than an implementation slip. Shipping a single shared key across a product family means that one extraction compromises the fleet. Leaving a production debug interface enabled, or shipping engineering firmware with diagnostic commands intact, hands an attacker the access the lifecycle state machine was meant to close. Omitting an update path guarantees that the first disclosed vulnerability is permanent. Relying on the secrecy of an interface or a protocol fails against anyone with an oscilloscope and patience. Trusting an unauthenticated bus between a host processor and an otherwise excellent secure element renders the secure element decorative. Finally, treating certification as the goal rather than the evidence produces products that pass an evaluation against a narrowly drawn security target while remaining trivially attackable outside it.
Summary
Design for Security is the DFX discipline that treats resistance to attack as a lifecycle design objective with an owner, a budget, and review gates. It begins with an explicit statement of assets and adversaries, converts risk into testable requirements allocated to hardware, firmware, and process, and drives architectural decisions, principally the form of the root of trust and the partitioning of the design, that set an upper bound on everything achievable later. It extends into the factory, where device identity, key provisioning, and hardware-enforced lifecycle states are manufacturing operations, and into the field, where update capability and cryptographic agility determine whether a vulnerability discovered in year three can be fixed at all.
Its defining characteristic among the DFX disciplines is the sharpness of its conflicts with the others. Security removes the observability that testability requires, adds the barriers that serviceability and recycling resist, and consumes area, test time, and support budget that cost engineering seeks to minimize. Those conflicts are resolvable only by joint decision early in development, informed by a realistic adversary and by the process standards and regulatory deadlines that now define the acceptable floor. Products that make those decisions deliberately ship with defensible security; products that defer them ship with whatever security their architecture happened to permit.