Attackers alter ASIC functionality requirements to cause a chip to be designed with hidden behaviour, weakened security controls, or unsafe access paths. This can create hard-to-detect backdoors that persist in hardware. Defenders should protect requirement baselines, enforce design review, and trace changes through formal approval and verification.
How attackers turn requirements into hidden hardware behaviour
Requirements are the first place an attacker can shape a hardware outcome without touching the final chip directly. If they can alter what the ASIC is supposed to do, they can steer design decisions toward hidden logic, relaxed checks, or alternate access paths that look legitimate on paper. The danger is that the defect is built into the silicon, not added later.
That makes requirement compromise especially dangerous in hardware programmes with many stakeholders, because a small wording change can cascade into architecture, implementation, and verification. A malicious change can survive reviews if teams treat the requirement as authoritative instead of treating it as something that must itself be protected, versioned, and independently challenged.
When the requirement baseline is weak, attackers do not need a dramatic exploit. They only need a believable specification change that gets accepted into the normal design flow, then the rest of the pipeline can faithfully manufacture the weakness.
How malicious requirement changes become backdoors
Attackers usually aim for one of three outcomes: hidden functionality, weakened security controls, or an unsafe access path. Hidden functionality can create a covert mode, diagnostic path, or alternate trust decision. Weakened controls can remove authentication checks, authorization boundaries, or integrity validation. Unsafe access paths can expose test interfaces, debug hooks, or privilege pathways that were never meant for production use.
The persistence risk is what makes this class of attack severe. Once a chip is fabricated, the malicious behaviour is embedded in hardware and can be difficult or impossible to remove without redesign or recall. That means the compromise can outlive the original attacker access and remain present across the product’s full deployment life.
For practitioners, the core issue is not just whether the design works, but whether the design can be trusted to enforce the security intent that was originally approved. A chip can pass functional tests and still contain a deliberate security weakness if the tests never asserted the right requirement in the first place.
What defenders should control in the requirement-to-silicon chain
Protecting against this threat starts before design begins. Requirement baselines should be change-controlled, access-restricted, and traceable to named approvers so that no one can quietly alter security-critical intent. Design reviews need to challenge not only the implementation, but also whether the underlying requirement is complete, consistent, and still aligned to the intended trust model.
Verification should trace security requirements all the way through implementation and test coverage. The point is to prove that the security property was preserved, not just that the chip functions. Where requirements touch privileged operations, interfaces, or debug paths, teams should demand explicit review of those paths rather than assuming they are harmless because they are “internal.”
Formal approval and verification matter because the attack is administrative as much as technical. If a requirement change can be inserted without durable traceability, then the organisation has no reliable way to prove that the security design it approved is the one it built.
Risk and Threat Considerations
This attack creates both supply-chain risk and embedded trust risk. The exposure is not limited to the single design document, because altered requirements can influence multiple downstream artefacts, from RTL and test plans to manufacturing and acceptance criteria.
Failure mechanism: A malicious or tampered requirement changes the security intent before implementation, so the resulting chip is built to include behaviour that should never have been approved, detected, or shipped.
Impact: The final hardware may contain persistent backdoors, weakened security controls, or hidden access paths that are hard to discover, hard to patch, and potentially exploitable at scale once deployed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Secures the design and change process where malicious requirement edits can enter. |
| Recommendation — Apply secure design and change review practices to catch tampered security requirements before implementation. | ||
| NIST SP 800-53 Rev 5 | SA-10 — Developer Configuration Management | Controls disciplined tracking and approval of specification changes that shape system design. |
| SA-11 — Developer Testing and Evaluation | Requires verification that implemented behaviour matches intended security requirements. | |
| CM-3 — Configuration Change Control | Directly governs controlled modification of baselines and specifications. | |
| Recommendation — Enforce formal baseline control and approval for requirement changes that affect security behavior. Validate that hardware requirements are tested against the approved security intent, not only functionally verified. Require authorization and traceability for every change to security-critical hardware requirements. | ||
Practitioner Guidance
What to verify: Treat security requirements as controlled assets. Verify that every change has an owner, a reviewer, an approval record, and a traceable link into design and validation evidence before it is allowed to influence implementation.
Common mistake: Relying on downstream testing alone. If a malicious requirement is accepted upstream, test coverage may faithfully confirm the wrong behaviour instead of exposing it.
Practitioner takeaway: The safest hardware programme is not the one that tests hardest at the end, but the one that makes requirement tampering visible before it can shape the design.