Why the 7 Foundational Requirements Matter
Within IEC 62443, the seven Foundational Requirements (FRs) define the core security properties that an embedded system must uphold. They are not features, controls, or checklists, but categories of technical responsibility that shape how a system is designed and validated:
- Identification and authentication of users, devices, and services
- Control over authorised actions
- Protection of system integrity
- Confidentiality of data at rest and in transit
- Controlled and segmented data flows
- Detection and handling of security-relevant events
- Availability of system resources under adverse conditions
Taken together, these requirements form a coherent model for “security by design”, exactly the principle enforced by the CRA. Importantly, they also map directly to CRA obligations such as vulnerability prevention, impact limitation, incident handling, and lifecycle risk management, a relationship that is made explicit in documents like Cyber Resilience Act Requirements – Standards Mapping.
From Requirements to Implementation
For embedded teams, the challenge is not understanding these requirements conceptually, but translating them into verifiable technical measures within constrained systems and complex supply chains. This is where tooling becomes relevant, not as a compliance shortcut, but as a means to maintain continuous control over these foundational properties throughout development and operation.
Technologies from developers such as Exein operate precisely at this intersection. By analysing firmware and enforcing runtime protections, Exein supports multiple Foundational Requirements simultaneously, particularly system integrity, restricted data flow, timely response to events, and resource availability. In a CRA context, this contributes to demonstrable risk reduction and supports the requirement to address vulnerabilities both before and after products are placed on the market.
Seen this way, the seven Foundational Requirements are not an abstract IEC construct, nor is the CRA a purely legal burden. Together, they define a single technical narrative: embedded systems must be designed, built, and maintained with explicit control over security-relevant behaviour and that control must be provable.
Translating theory into proof
What takes a reverse engineer weeks, our automated scan uncovers in seconds. From CVE detection and malware traces to hidden crypto keys and hardcoded passwords: get instant visibility into your firmware’s security posture.
Want to know what’s hiding inside your firmware?