Trace findings to requirements. Keep gaps visible.
FDIE maps assessed firmware evidence to ETSI EN 303 645, EN 18031, OWASP FSTM, NIST SP 800-193, NIST IR 8259A, IEC 62443-4-2, IEC 81001-5-1, FDA 524B and TEC 31318, with grades for assessed controls and explicit coverage gaps. CRA disclosure review is available separately; automated CRA conformity grading is not currently offered.
Last updated September 16, 2026
Review coverage across frameworks.
See assessed coverage and items requiring manual review across the firmware fleet. This example shows six complete framework cards from the review workspace.
Eleven control-assessment frameworks.
FDIE maps available results from its 60-point test suite to supported requirements. Grades summarise assessed controls, not an entire standard. Missing evidence remains visible. CRA disclosure review is a separate workflow and has no conformity grade.
A technical standard, a legal obligation and a procurement or contract requirement have different scopes. Product category, market, version and exclusions determine applicability. See the European Commission’s CRA guidance and FDA cybersecurity guidance. The mappings below describe FDIE’s assessment coverage, not a determination that every framework applies to your product.
View the versioned technical mapping inventory
| Framework | Scope | Context | FDIE mapping |
|---|---|---|---|
| EU Cyber Resilience Act (CRA) | Products with digital elements placed on the EU market, subject to scope and exclusions | Separate disclosure review and submission records; no conformity grade | |
| ETSI EN 303 645 | Consumer IoT | Supported requirement mappings | |
| OWASP FSTM | Firmware assessment | Supported methodology mappings | |
| NIST SP 800-193 | Platform firmware | Supported requirement mappings | |
| NIST IR 8259A | IoT devices | Supported requirement mappings | |
| IEC 62443-4-2 | Industrial and OT components | Supported requirement mappings | |
| EN 18031-1 | EU, radio equipment (RED Article 3.3(d), network security) | Category-level mapping | |
| EN 18031-2 | EU, radio equipment (RED Article 3.3(e), privacy) | Category-level mapping | |
| EN 18031-3 | EU, radio equipment (RED Article 3.3(f), monetary value) | Article and mechanism-family mapping | |
| IEC 81001-5-1 | Global, health software and medical devices | Category-level mapping | |
| FDA FD&C Act 524B | US, cyber devices (premarket submissions) | Category-level mapping | |
| TEC 31318:2025 | India, consumer IoT (Telecommunication Engineering Centre) | Supported requirement mappings |
Follow a framework into its checks.
Select a firmware image, review the mapped checks and distinguish recorded outcomes from items needing manual assessment. This ETSI example keeps the coverage limits and credential-check rows in view.
60 test cases across 9 categories.
Grades summarize assessed technical checks. Missing evidence remains unassessed; firmware analysis alone cannot establish product conformity.
Credential security
Hardcoded passwords, default credentials, and weak or reused secrets baked into firmware.
Firmware update
Available evidence of update mechanisms, signing and rollback controls; device-level validation may still be needed.
Cryptography
Weak ciphers, deprecated algorithms, hardcoded keys, and insecure key storage or generation.
Binary hardening
Compiler-level protections: stack canaries, ASLR/PIE, RELRO, NX, and stripped symbols.
Attack surface
Configured services and firmware indications of debug interfaces. Runtime bindings and physical-device exposure require separate evidence.
Known vulnerabilities
CVE matching against 385,000+ records with CPE version-range filtering, EPSS scoring, and CISA KEV flagging.
Secure boot
Boot metadata, signature indicators and trusted-execution configuration where available; these alone do not validate the hardware trust chain.
Runtime behaviour
Observed execution, crashes and behaviour during supported emulation, with the method and coverage limits recorded.
Code security
Command injection, unsafe file paths, unescaped web output and untrusted data reaching interpreters in shipped scripts.
Maintain evidence for your CRA preparation.
Article 14 reporting began on 11 September 2026 for actively exploited vulnerabilities and severe security incidents. The main CRA obligations apply from 11 December 2027. Product scope and exclusions need assessment; buying a scanner does not establish conformity. Read the European Commission CRA overview.
FDIE helps maintain technical evidence between releases. Your team remains responsible for product risk assessment, vulnerability handling, reporting and conformity documentation.
Article 14
Document disclosure decisions
A CVE match is a review signal, not proof of active exploitation. Reporting deadlines run from manufacturer awareness, not from completing an FDIE assessment. Record awareness, decisions and submissions alongside the evidence. See reporting guidance.
Technical evidence
Reviewable SBOM and VEX exports
Export identified components, recorded vulnerability assessments and supporting evidence. Check completeness and applicability before using them in your product documentation.
Grade
Conformity grading not offered
Use technical evidence, SBOMs and documented assessments to support your review. FDIE does not currently issue an automated CRA conformity grade or a certification.
Compliance questions, answered plainly.
Have a question about your product? Talk to our team.
[email protected]CRA & disclosure
What is the EU Cyber Resilience Act and when does it take effect?
The CRA sets cybersecurity requirements for products with digital elements placed on the EU market, subject to product-specific scope and exclusions. Article 14 reporting began on 11 September 2026; the main obligations apply from 11 December 2027. FDIE supports evidence collection and disclosure review, not automated conformity grading or certification.
What is Article 14 of the EU Cyber Resilience Act?
Article 14 covers reporting of actively exploited vulnerabilities and severe security incidents. Early-warning and notification deadlines run from manufacturer awareness; completing an FDIE assessment does not start or defer them. FDIE records assessments, awareness time and submission references. A CVE match, KEV entry or EPSS score alone does not establish product reportability or submit a notification. Consult the European Commission reporting guidance for the applicable stages and deadlines.
How does FDIE's compliance grade map to the EU CRA's annexes?
FDIE does not currently offer an automated CRA conformity grade. Technical findings, SBOMs and disclosure records can support a product assessment; organizational processes and missing technical evidence require additional review.
Frameworks & coverage
What is ETSI EN 303 645 and does it apply to my product?
ETSI EN 303 645 is a security baseline for consumer IoT, including credentials, updates and vulnerability handling. Check its relevance to your product and applicable requirements. FDIE maps available technical evidence to supported provisions; a grade summarises assessed checks and does not establish compliance with the entire standard.
What is NIST SP 800-193 and who requires it?
NIST SP 800-193 provides platform firmware resiliency guidelines covering protection, detection and recovery. FDIE maps available firmware evidence to supported requirements and reports gaps. Confirm any procurement-specific obligations separately; image analysis alone cannot validate all hardware and operational controls.
What is IEC 62443-4-2 and who needs it?
IEC 62443-4-2 defines technical security requirements for components used in industrial automation and control systems (IACS), and is widely required contractually for industrial and operational-technology (OT) firmware. FDIE evaluates binary hardening, credential handling, and cryptography against IEC 62443-4-2's component-level requirements as one of its eleven offered frameworks.
Which compliance frameworks does FDIE support?
Eleven: ETSI EN 303 645, EN 18031-1, EN 18031-2 and EN 18031-3 (the Radio Equipment Directive harmonised standards for network security, privacy and monetary value), OWASP FSTM, NIST SP 800-193, NIST IR 8259A, IEC 62443-4-2, IEC 81001-5-1 for health software, FDA premarket cybersecurity under FD&C Act section 524B, and India's TEC 31318:2025 code of practice for consumer IoT. Assessed controls are scored from the same 60-point test suite; missing evidence remains unassessed. CRA disclosure review is separate from conformity grading. Where a standard's numbered requirements are not public, FDIE cites the category rather than inventing a clause number, and says so in the report.
Keep technical evidence current between releases.
Review a sample comparison with us. Then scope a supported image pair, hosting requirements and the evidence your team needs to evaluate.
21-day free trial on the full platform. No card, no automatic conversion.