A requirement is not evidence that the product behaves securely. Regulation can demand secure update mechanisms, protection of sensitive data or access control, but the wording at requirement level does not establish whether the implemented product enforces the intended property. A product may use signed firmware updates and still accept vulnerable legacy firmware through a recovery path; use certificates and still share credentials across a product line.
The technical gap runs between "the requirement exists" and "the implemented product demonstrably enforces the intended security property". Closing that gap is an engineering task: translate the requirement into a concrete security property, map it to the product architecture, follow it into the components that enforce it, and test whether it holds under attack.
This is deliberately not compliance consulting. Certification, legal interpretation and regulatory assessment are outside this scope. What regulation creates is a buying trigger for technical work: the manufacturer needs evidence, and evidence comes from testing the product, not from documenting intentions.
Regulatory requirements become concrete technical questions.
- Secure update Do firmware signing, verification, rollback protection, recovery and key handling actually prevent unauthorized or vulnerable software from being installed?
- Authentication & access control Which identities can reach product functions, management interfaces and privileged operations, and are those boundaries enforced consistently?
- Device identity & credentials Are product identities unique, protected, provisioned securely and replaceable if compromised?
- Communication security Do pairing, protocol authentication, encryption, freshness and replay protection establish the intended trust relationship?
- Production security state Are debug interfaces, readout protection and lifecycle configuration consistent with the intended production state?
- Vulnerability handling evidence Can reported issues be reproduced, their product impact established, affected versions identified and fixes independently verified?
The requirement said secure update. The recovery path disagreed.
The technical file documents a signed firmware update mechanism, requirement met on paper. The implementation verifies signatures on the normal path, while the recovery path accepts an older, validly signed image without version enforcement.
A technical test that walks the requirement into the product, through architecture and implementation to a concrete attack, shows the property does not hold. The documentation was accurate about the mechanism; the mechanism was not the whole product.
Translate the requirement into something the product can prove.
We identify the relevant technical security property behind each requirement, map it to the product architecture and follow it into the components that enforce it. Depending on the requirement, that leads into firmware, identity systems, protocols, applications or backend services, and ends with evidence from testing, not assertion.
- CRA timeline approaching for your product category
- EN 18031 applies to radio equipment
- IEC 62443 required in industrial customer projects
- Customer or tender demands documented security testing
- Preparing a conformity or technical file
- Deciding which requirements need testing versus documentation