For engineers
Selling to industry or the US? What firmware can evidence
By Manish SharmaPublished 9 min read
Industrial and US buyers ask for different security baselines, and much of the proof sits in the firmware. IEC 62443-4-2 sets technical requirements for industrial automation components at capability security levels 1 to 4. NIST IR 8259A and NIST IR 8425 are voluntary US baselines for IoT devices and consumer IoT products. The FCC adopted NIST IR 8425 as the basis of its Cyber Trust Mark. In FDIE's catalogue, firmware evidence helps with 8 of the 47 IEC component requirements, 7 of NIST IR 8259A's 22 capabilities and 8 of NIST IR 8425's 33 outcomes. It decides none of them alone. Identity, configuration, documentation and support need your team.
In short
- IEC 62443-4-2 sets requirements for industrial components at security levels 1 to 4, while NIST IR 8259A and 8425 are voluntary US baselines for IoT devices and products.
- Firmware evidence helps with 8 of 47 IEC requirements, 7 of 22 NIST IR 8259A capabilities and 8 of 33 NIST IR 8425 outcomes, but decides none alone.
- Identity, configuration, documentation and support sit with your team, so plan that work alongside the firmware fixes.
Three documents, three audiences
These documents come from different worlds: industrial automation buyers, US federal guidance and consumer labelling, and the table below puts them side by side.
| IEC 62443-4-2 | NIST IR 8259A | NIST IR 8425 | |
|---|---|---|---|
| Published by | IEC; ISA publishes it as ANSI/ISA-62443-4-2-2018 | NIST | NIST |
| Date | Edition 1.0, 27 February 2019 | May 2020 | September 2022 |
| Status | Voluntary standard; certified through schemes such as ISASecure CSA | Voluntary guidance | Voluntary guidance; the basis of the FCC's Cyber Trust Mark |
| Target | Components of industrial automation and control systems | IoT devices | Consumer IoT products: the device plus its app, cloud and hubs |
| Structure | Seven foundational requirements, component requirements, capability levels 1 to 4 | Six device capabilities | Six technical and four non-technical outcome areas |
| Items in FDIE's catalogue | 47 | 22 | 33 |
IEC 62443-4-2 in brief
IEC 62443-4-2 lists technical requirements for a component, grouped under seven foundational requirements. The IEC abstract names them as:
- identification and authentication control
- use control
- system integrity
- data confidentiality
- restricted data flow
- timely response to events
- resource availability
The standard defines capability security levels for a component, written SL-C, from 1 to 4. Target and achieved levels are out of its scope. It covers four component types: software applications, embedded devices, host devices and network devices.
Certification usually goes through a scheme, and ISASecure's Component Security Assurance (CSA) has four parts:
| CSA element | What it checks |
|---|---|
| SDLA | The supplier's development process, against IEC 62443-4-1 |
| SDA-C | The development artifacts for this component |
| FSA-C | The component's security functions; more requirements apply at higher levels |
| VIT-C | A scan of the component for known vulnerabilities |
A firmware analysis is closest in spirit to VIT-C and gives part of the input to FSA-C. It does not touch the process side, which is half the scheme.
Where firmware fits in IEC 62443-4-2
Device checks give part of the evidence for 8 of the 47 component requirements in our catalogue. None is decided by firmware alone, because the standard asks how the function behaves at the level you claim.
| Requirement | Firmware evidence (device checks) |
|---|---|
| CR 1.1 Human user identification and authentication | No published default credentials |
| CR 1.5 Authenticator management | No hard-coded credentials, strong password hashes, no API keys, tokens or private keys in the image, no account without a password |
| CR 1.11 Unsuccessful login attempts | Brute-force protection on sign-in |
| CR 2.1 Authorization enforcement | Telnet and FTP off, no debug tools or serial shell, only needed services, web server not running as root, only root with user id 0 |
| CR 3.4 Software and information integrity | Updates verified by signature, boot loader verifies signatures, no test keys and a current revocation list in UEFI Secure Boot |
| CR 3.5 Input validation | Injection checks on scripts and the web interface; two runtime checks still in development |
| CR 4.1 Information confidentiality | No clear text credentials, TLS 1.2 or later, no weak ciphers or hashes, management over HTTPS |
| CR 6.1 Audit log accessibility | Security events are logged |
The other 39 need your evidence, together with the security level you claim. They include session lock and termination, timestamps, boot process integrity, denial of service protection, backup and recovery, and the component inventory.
The level changes the bar, not the evidence. A private key shipped in the image counts against authenticator management whatever level you claim. A missing session lock may be acceptable at one level and fail at a higher one, because more requirements apply as the level rises. That is why the app marks these eight as partly automatic: the firmware shows what is there, and the assessor decides whether it is enough for the level.
NIST IR 8259A: six device capabilities
NIST IR 8259A lists what a device should be able to do, without saying how. Its six capabilities are:
- device identification
- device configuration
- data protection
- logical access to interfaces
- software update
- cybersecurity state awareness
Firmware evidence helps with 7 of the 22 items in our catalogue.
| Capability | Item | Firmware evidence |
|---|---|---|
| Device configuration | Changes only by authorised entities | No published default credentials |
| Data protection | Secure cryptographic modules | TLS 1.2 or later, valid certificates, no SSL 2 or 3, HTTPS management |
| Logical access to interfaces | Unneeded interfaces can be disabled | Telnet off, only needed services |
| Logical access to interfaces | Access only for authorised entities | No hard-coded credentials, no account without a password, brute-force protection |
| Software update | Software can be updated | Updates downloaded over an encrypted channel |
| Software update | Updates verified before install | Updates verified by signature |
| Cybersecurity state awareness | Security state reported | Security events are logged |
Unique logical and physical identifiers, restoring a secure configuration, rollback, lockout settings and most of state awareness need your evidence, usually a test report or a design document.
NIST IR 8425: the product view
NIST IR 8425 builds on NIST IR 8259A and 8259B and looks at the whole product, not just the device. The FCC's order counts three kinds of extra components: hubs, companion apps and back-end services.
It has six technical outcome areas and four non-technical ones:
- documentation
- information and query reception
- information dissemination
- product education and awareness
In our catalogue, firmware evidence helps with 8 of 33 outcomes and product data fills 2 more.
| Outcome | How FDIE decides it |
|---|---|
| Data Protection 1, 3 (stored data and data in transit) | Partly, from credential, key and TLS checks |
| Interface Access Control 1(a), 1(b), 1(c) (needed interfaces, access control, least privilege) | Partly, from service, credential and privilege checks |
| Interface Access Control 2(a) (data between components validated) | Partly, from injection checks |
| Software Update 1 (verified updates) | Partly, from update checks |
| Cybersecurity State Awareness 1 | Partly, from logging |
| Information and Query Reception 1(a) (contact for vulnerability reports) | From your declared security contact |
| Product Education and Awareness 1(e) (information for buying decisions) | From your declared support period |
| The other 23 | Your evidence |
The firmware is only one part of an 8425 product. The companion app and the cloud need their own review, and FDIE's code analysis can read their source if you connect those repositories.
The Cyber Trust Mark, as the FCC records it
The label is voluntary and its set-up is still moving, so check the FCC docket before you plan a launch around it. The NIST outcomes are worth meeting either way, because US buyers and labelling programmes start from them.
- March 2024: the FCC adopted a voluntary labelling programme for consumer wireless IoT products, with NIST IR 8425 as its basis.
- December 2025: UL Solutions withdrew as lead administrator, effective 19 December.
- January 2026: the FCC opened new filing windows, one for a lead administrator and one for more label administrators. By then it had conditionally approved 11 of them.
Side by side
The same firmware facts answer all three documents, which is why one analysis per release is enough.
| Topic | IEC 62443-4-2 | NIST IR 8259A | NIST IR 8425 | Firmware evidence |
|---|---|---|---|---|
| Authentication and default credentials | CR 1.1, CR 1.5, CR 1.11 | Logical access 2 | Interface Access Control 1(b) | Default and hard-coded credentials, password hashes, brute-force protection |
| Least functionality | CR 2.1 | Logical access 1 | Interface Access Control 1(a), 1(c) | Telnet, FTP, debug tools, serial shell, services, privileges |
| Integrity and updates | CR 3.4 | Software update 1, 2 | Software Update 1 | Update and boot signatures, Secure Boot keys |
| Input validation | CR 3.5 | None | Interface Access Control 2(a) | Injection checks |
| Confidentiality | CR 4.1 | Data protection 1 | Data Protection 1, 3 | TLS, ciphers, key sizes, clear text credentials |
| Logging | CR 6.1 | State awareness 1 | State Awareness 1 | Security events logged |
| Identity | CR 1.2, CR 1.4 | Device identification 1, 2 | Asset Identification 1, 2 | None; your evidence |
Where to start, by product
The right starting point depends on who buys the device, so we split the advice by product type.
An industrial gateway or controller. Agree the target security level with your customer before any testing starts. Then fix what the firmware shows for the eight requirements above, because those findings are cheap to fix at your desk. Put the IEC 62443-4-1 development process in place early, since a certification scheme such as ISASecure CSA assesses it alongside the component. Your SBOM is a natural start for the component inventory in CR 7.8, although our catalogue leaves that requirement to your evidence.
A consumer device for the US market. Treat NIST IR 8425 as a checklist for the whole product, not only the firmware. Declare a support period and a security contact, because buyers and labels look for both. Write the documentation outcomes while the design is fresh, and have the app and cloud reviewed with the same care as the device.
A device sold in both worlds. One analysis per release answers the firmware rows of all three documents. Keep the people side in one place too, so an identity or update policy is written once and reused.
Limits we state plainly
These mappings help you find gaps early, but they are not an assessment, and three limits apply to them.
- The IEC text: IEC sells the standard, and we could not read it for our catalogue. Requirement numbers and names follow its public structure, and the app tags each one "Clause to be confirmed".
- Common requirements only: our 47 entries are the common component requirements, not the extra ones the standard sets for each component type.
- Static analysis: nothing in the image is run today, so the two runtime checks behind input validation stay unassessed.
The app offers IEC 62443-4-2 for products of device type Gateway. It gives evidence and finds gaps; a certification body or your customer's assessor makes the decision. For the full list by market, see device security frameworks by market.
Questions
What are the security levels in IEC 62443-4-2?
IEC 62443-4-2 defines requirements for capability security levels 1 to 4 of a component, SL-C. In ISASecure's CSA certification, higher levels bring more functional requirements, while the development artifact review and vulnerability testing are the same at every level except for the residual risk allowed.
What is the difference between NIST IR 8259A and NIST IR 8425?
NIST IR 8259A (May 2020) lists six capabilities an IoT device should have. NIST IR 8425 (September 2022) builds on it and NIST IR 8259B to cover the whole consumer IoT product, including its app and cloud. It also adds non-technical outcomes such as documentation and support information.
Is the U.S. Cyber Trust Mark mandatory?
No. The FCC set it up in March 2024 as a voluntary labelling programme for consumer wireless IoT products, with NIST IR 8425 as its basis. Its lead administrator withdrew in December 2025, so check the FCC docket for its current state.
Can a firmware analysis prove an IEC 62443-4-2 security level?
No. It gives evidence for some component requirements, such as authenticator management and software integrity. The level is assessed against the full standard, together with the development process of IEC 62443-4-1.
Sources
- IEC 62443-4-2:2019, Technical security requirements for IACS components (IEC webstore) webstore.iec.ch
- ISA, the ISA/IEC 62443 series of standards isa.org
- ISASecure, IEC 62443 Component Security Assurance (CSA) certification isasecure.org
- NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline csrc.nist.gov
- NIST IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products csrc.nist.gov
- FCC, Cybersecurity Labeling for Internet of Things, Report and Order FCC 24-26, 15 March 2024 (PDF) docs.fcc.gov
- FCC, Public Notice DA 26-75 on the U.S. Cyber Trust Mark programme, 26 January 2026 (PDF) docs.fcc.gov
Product and project names are trademarks of their owners, used only to identify the public firmware, software and standards discussed. MAGDOX is not affiliated with or endorsed by them.