IEC 62443-4-2
technical security requirements for industrial automation and control system components
IEC 62443-4-2 (Security for industrial automation and control systems, Part 4-2: Technical security requirements for IACS components) is the international standard that defines the per-component technical security capability industrial automation and control system components must offer at each Security Level. It elaborates the seven foundational requirements (Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability) into per-component requirements (CRs) and Requirement Enhancements (REs), tailored across four component types (embedded device, network device, host device, software application) and four Security Levels (SL 1 to SL 4). This page covers the FR and CR set, the Security Levels and REs, the per-component evidence pack the assessment produces, the relationship with IEC 62443-4-1, IEC 62443-3-3, the wider 62443 family, the EU Cyber Resilience Act, Common Criteria, and the audit-grade evidence pack a 62443-4-2 programme runs on.
No credit card required. Free plan available forever.
IEC 62443-4-2 explained for OT product suppliers, AppSec teams, and product security teams
IEC 62443-4-2 (Security for industrial automation and control systems, Part 4-2: Technical security requirements for IACS components) is the international standard that defines the per-component technical security requirements industrial automation and control system components must meet at each Security Level. It is the technical-side anchor in the wider IEC 62443 family, paired with the process-side SDL requirements of IEC 62443-4-1. The standard reuses the seven foundational requirements (Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability), elaborates per-component requirements (CRs) under each FR, defines Requirement Enhancements (REs) that lift the base CR to a higher Security Level, and assigns per-CR capability expectations at SL 1 through SL 4.
For OT product manufacturers, embedded device makers, ICS suppliers, industrial network equipment vendors, medical device manufacturers, IIoT platform suppliers, and host device suppliers shipping into asset owners that operate under 62443, the standard is the technical capability reference customer procurement evaluations, system integrators (under 62443-2-4), asset owners running 62443-3-2 risk assessments, certification bodies (ISASecure CSA, ISASecure EDSA, TUV-style assessors), and the conformity assessment routes under the EU Cyber Resilience Act all read against. For AppSec teams and product security teams inside supplier organisations producing per-CR evidence and per-Security-Level capability matrices alongside broader application security programmes, the standard is the OT component-side reference paired with system-level NIST SP 800-82 guidance for asset-owner deployments.
This page walks through the scope of the standard, the seven foundational requirements and their component requirements, the four Security Levels and how they layer through Requirement Enhancements, the per-component evidence pack the assessment produces, the failure modes the standard surfaces, the relationship with adjacent regimes (62443-4-1, 62443-3-3, the wider 62443 family, the EU Cyber Resilience Act, Common Criteria, UNECE R155), and where IEC 62443-4-2 sits alongside the security feature launch readiness evidence pack workflow, the PSIRT product security incident response workflow, and the SBOM and VEX publishing workflow. Suppliers that adopt 62443-4-2 as the per-component capability reference produce an evidence pack that holds up across the ISASecure CSA or EDSA assessment, customer-side procurement security evaluations, system-integrator readiness checks, and internal audit on one operating record.
What IEC 62443-4-2 covers
The standard is the international anchor for per-component technical security capability for industrial automation and control systems. It is structurally distinct from any single internal product security baseline and narrower than the wider 62443 family; the boundary is the component itself and the per-CR capability evidence the supplier produces against the per-Security-Level expectations. Read sequentially against the CR set, the standard answers what capability the component offers rather than how the customer-side zone-and- conduit architecture wraps it.
Technical component requirements, not process requirements
IEC 62443-4-2 is the technical side of the 62443-4 series. It defines the security requirements an industrial automation and control system component must meet at each Security Level. The companion standard IEC 62443-4-1 is the process side: the secure development lifecycle the supplier follows when building the component. Programmes typically pair the two: 4-1 evidences how the product is built; 4-2 evidences what the product does. ISASecure SDLA certifies the process side under 4-1; ISASecure CSA or EDSA certifies the product side under 4-2.
Organised around the seven foundational requirements and four Security Levels
The standard reuses the seven foundational requirements established in IEC 62443-3-3 (Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability) and elaborates per-component requirements (CRs) and Requirement Enhancements (REs) under each FR. Each requirement carries a per-Security-Level (SL 1 to SL 4) capability expectation. A 62443-4-2 evidence pack walks each CR against the achieved capability on the component as shipped.
Four component types: embedded, network, host, software application
The standard differentiates component types: embedded devices (PLCs, RTUs, IEDs, sensors, actuators with constrained compute), network devices (industrial switches, routers, firewalls, gateways), host devices (engineering workstations, operator stations, historians), and software applications (SCADA platforms, batch managers, asset management software). Requirements are common across types where the capability applies, with component-type-specific tailoring where the runtime constraints differ. The CR set the assessor reads depends on the declared component type.
The seven foundational requirements and their component requirements
The seven foundational requirements are the structural core of the standard. Each FR elaborates a set of per-component requirements (CRs) and Requirement Enhancements (REs). The CR set is the structural baseline at each Security Level; the RE set is the structural pathway to higher Security Levels. Read sequentially across the FR set, the standard covers the full technical capability surface a component is expected to offer.
- 1
FR 1: Identification and Authentication Control (IAC)
Requirements that establish who or what is requesting access to the component. CR 1.1 through CR 1.14 cover human user identification and authentication, software process and device identification and authentication, account management, identifier management, authenticator management, wireless access authentication, strength of public key authentication, authenticator feedback, unsuccessful login attempts, system use notification, access via untrusted networks, strength of password-based authentication, and identification and authentication for guest users. Higher Security Levels add multifactor authentication, public-key infrastructure, and stronger feedback obfuscation.
- 2
FR 2: Use Control (UC)
Requirements that constrain what an authenticated identity is permitted to do. CR 2.1 through CR 2.13 cover authorisation enforcement, wireless use control, use control for portable and mobile devices, mobile code, session lock, session termination, concurrent session control, auditable events, audit storage capacity, response to audit processing failures, timestamps, non-repudiation, and use of physical diagnostic and test interfaces. Higher Security Levels add finer-grained authorisation, more rigorous session controls, and stronger physical interface protections.
- 3
FR 3: System Integrity (SI)
Requirements that protect the integrity of the component, its data, and the communication channels it participates in. CR 3.1 through CR 3.14 cover communication integrity, malicious code protection (on host and embedded devices where applicable), security functionality verification, software and information integrity, input validation, deterministic output, error handling, session integrity, protection of audit information, software and firmware update authenticity, the use of physical diagnostic and test interfaces, and integrity check on the boot process. Higher Security Levels add stronger cryptographic protections and runtime integrity verification.
- 4
FR 4: Data Confidentiality (DC)
Requirements that protect the confidentiality of information at rest and in transit. CR 4.1 through CR 4.3 cover information confidentiality, information persistence, and use of cryptography. Component type matters: embedded devices with constrained compute carry tailored cryptography expectations; host devices and software applications carry fuller expectations. Higher Security Levels expect stronger algorithms, stronger key management, and confidentiality protection across more interfaces.
- 5
FR 5: Restricted Data Flow (RDF)
Requirements that constrain how data flows through the component and the networks it connects to. CR 5.1 through CR 5.4 cover network segmentation support, zone boundary protection, general purpose person-to-person communication restrictions, and application partitioning. The CR set is most consequential for network devices and gateways, where the boundary protection capability the component offers shapes the zone-and-conduit architecture the asset owner builds around it.
- 6
FR 6: Timely Response to Events (TRE)
Requirements that ensure security-relevant events are recorded and surfaced for response. CR 6.1 through CR 6.2 cover audit log accessibility and continuous monitoring. The CR set reads against the operating-environment expectations under IEC 62443-2-1 and the asset-owner-side patch management cadence under IEC 62443-2-3. Higher Security Levels expect richer audit content, more reliable log delivery, and stronger tamper-evidence on the audit trail.
- 7
FR 7: Resource Availability (RA)
Requirements that protect the availability of essential component functions under load, fault, or attack conditions. CR 7.1 through CR 7.8 cover denial-of-service protection, resource management, control system backup, control system recovery and reconstitution, emergency power, network and security configuration settings, least functionality, and control system component inventory. Availability is the foundational requirement most distinct from typical IT security regimes, reflecting the operational-technology priority on continuous safe operation.
The four Security Levels
The standard names four Security Levels (SL 1 through SL 4) per CR. A component capability matrix typically carries different Security Level claims across the seven FRs: a network device with strong cryptographic capability at SL 3 on FR 1 (authentication) and FR 4 (data confidentiality) but SL 2 on FR 6 (timely response to events) reflects the per-FR pattern. The ISASecure CSA or EDSA assessment reads the per-CR achieved Security Level rather than a single component-wide claim, and the component data sheet that ships with the product carries the same per-FR pattern.
| Security Level | What it looks like in practice |
|---|---|
| Security Level 1: Protection against casual or coincidental violation | The baseline capability set. Designed to resist accidental or careless behaviour by authorised users, casual misuse, and unintentional exposure. Most general-purpose IT-style controls (named accounts, basic authentication, audit logging) meet SL 1. Components shipping with SL 1 capability are appropriate for low-criticality zones where the threat model is dominated by error rather than intent. |
| Security Level 2: Protection against intentional violation using simple means | Resistance to intentional misuse using low-resource generic means: basic offensive tools, low motivation, low skill. CRs at SL 2 typically add stronger authentication (where SL 1 accepted simple passwords, SL 2 expects strength expectations and lockout), tighter session controls, and more rigorous audit content. Most commercial OT components ship with SL 2 capability across the seven FRs. |
| Security Level 3: Protection against intentional violation using sophisticated means | Resistance to intentional misuse using moderate-resource OT-specific means: targeted offensive tooling, moderate motivation, moderate skill, OT-specific knowledge. CRs at SL 3 typically add multifactor authentication for human users, stronger cryptography on confidentiality and integrity protections, richer continuous monitoring, and stronger zone boundary protection. Higher-criticality zones in regulated sectors (utilities, transportation, pharma) often target SL 3. |
| Security Level 4: Protection against intentional violation using sophisticated means with extended resources | Resistance to intentional misuse using extensive resources, advanced motivation, and OT-specific expertise (nation-state actor threat model). CRs at SL 4 typically expect the strongest cryptographic protections, hardware-rooted integrity verification, the most rigorous tamper-evidence on audit trails, and the strongest availability protections. SL 4 is rarely the per-zone target across an entire estate; programmes typically target SL 4 on the highest-consequence zones only. |
The per-component evidence pack the assessment produces
The standard expects a defined artefact set per component rather than a single document. The pack below is the minimum durable set most supplier programmes maintain when they adopt IEC 62443-4-2 as the per-component capability reference. Each artefact has a named owner, a refresh cadence, and a version history so reconstruction at certification time is replaced with a continuous operating trail tied to firmware release.
- A component scope declaration that names the component type (embedded device, network device, host device, software application), the firmware or software version under assessment, the configuration baseline assumed for the assessment, the intended deployment environment, and the customer-side security responsibilities the component depends on. The declaration is the artefact the ISASecure CSA or EDSA assessor reads first when scoping the assessment and the customer-side procurement reads when comparing components.
- A per-CR capability matrix that walks each component requirement from the standard against the achieved capability on the component as shipped. The matrix records the CR identifier, the FR family, the target Security Level the supplier claims, the achieved Security Level evidence, the per-CR test or analysis method used to verify the claim, and the closure trail for any partial conformance. The matrix is the artefact that turns a 62443-4-2 claim from a brochure assertion into a defensible evidence record.
- A Requirement Enhancement evidence record per RE that supports the higher-Security-Level capability claims. REs elaborate the base CR (typically adding stronger cryptography, multifactor authentication, finer-grained authorisation, or stronger tamper-evidence). Each RE the supplier claims carries its own per-CR evidence record. The RE set is the differentiator between SL 2 and SL 3 capability on the same component.
- A component test report per CR that walks the verification method (security functional test, vulnerability test, structured code analysis, penetration test, configuration analysis), the test environment integrity evidence (firmware build hash, configuration baseline, test harness version), the per-CR pass and fail outcomes, the partial-conformance dispositions, and the test re-execution trail across firmware releases. The test report pairs with the 62443-4-1 SVV (Security Verification and Validation Testing) practice on the supplier side.
- A vulnerability handling cross-reference that ties each security-related issue identified during component assessment or post-release vulnerability disclosure to the affected CR. Issues that affect a CR claim trigger a re-evaluation of the per-CR capability matrix and, where the CR claim no longer holds, a customer-facing security advisory. The cross-reference pairs with the 62443-4-1 DM (Management of Security-Related Issues) practice on the supplier side.
- A security-relevant configuration baseline document that names the default configuration the component ships with, the configuration changes the secure-by-default posture depends on, the hardening steps the integrator or asset owner applies to reach the SL claim, and the documentation traceability into the 62443-4-1 SG (Security Guidelines) practice output. The baseline is the artefact the system integrator reads when applying 62443-2-4 controls and the asset owner reads when operating under 62443-2-1.
- A component decommissioning and end-of-life record that names the secure decommissioning steps, the secure data sanitisation steps for any persistent storage on the component, the secure key destruction steps where the component uses cryptographic material, the customer-facing end-of-life security communication, and the timeline for the end of security update support. The record pairs with the 62443-4-1 SG practice and the EU Cyber Resilience Act post-market obligations.
- A customer-facing component security data sheet that summarises the supported Security Levels per FR, the supported authentication mechanisms, the cryptographic algorithm and key length expectations, the audit log content and delivery options, the zone boundary protection capabilities (for network devices), the resource availability characteristics under load, and the conformance claim against ISASecure CSA or EDSA where applicable. The data sheet is the artefact the procurement-side technical evaluation reads during component selection.
Failure modes the standard surfaces
The standard is permissive on the choice of test tooling, the wording of the per-CR evidence narrative, and the structural format of the component security data sheet. It is unforgiving about a small number of patterns that turn the 62443-4-2 claim from a defensible technical capability claim into a marketing assertion. The patterns below recur across supplier programmes and are the ones that erode procurement-side confidence, certification credibility, and CRA conformity assessment defensibility most reliably.
- Treating the SL claim as a single number across the component. Suppliers that publish a single SL claim ("this component is SL 2") without per-FR decomposition produce a marketing assertion the assessor cannot validate. The standard expects the SL claim to be carried per CR and per FR, with the achieved Security Level per requirement explicit. A component that meets SL 3 on FR 1 and SL 2 on FR 3 carries that per-FR pattern on the capability matrix rather than averaging to a single misleading number.
- Confusing SL-C (capability), SL-T (target), and SL-A (achieved). The standard names three distinct Security Levels for the same zone or component: SL-C is the capability the component can provide (the 62443-4-2 claim), SL-T is the target the asset owner sets per zone during 62443-3-2, SL-A is the achieved level after assessment and operation. Suppliers that conflate the three produce evidence the assessor cannot map back to the customer-side zone-and-conduit assessment.
- No per-component-type tailoring. The standard differentiates CR expectations by component type (embedded, network, host, software application). Suppliers that publish a single CR set for a portfolio spanning multiple component types produce evidence that does not align with the per-type expectations. A network device CR set and an embedded device CR set differ materially on cryptographic capability, audit log delivery, and zone boundary protection.
- CR claims without RE evidence at the higher Security Levels. The Requirement Enhancements (REs) are the structural pathway from SL 1 baseline capability to SL 3 and SL 4 stronger capability. Suppliers that claim SL 3 without the RE-level evidence (multifactor authentication, stronger cryptography, finer-grained authorisation) produce a claim the assessor reads against the structural expectation and rejects. The RE set is not optional decoration on the CR.
- Verification by analysis alone for testable requirements. The standard expects verification methods proportionate to the CR (functional test, vulnerability test, penetration test, structured code analysis, configuration analysis). Suppliers that use analysis-only verification for CRs the standard expects to be tested empirically produce evidence that the assessor reads as a documentation exercise. The verification method per CR sits on the test report and is the assessor reads against the appropriateness of the method.
- No regression of CR evidence across firmware releases. Suppliers that verify the CR set against one firmware release and never re-execute the verification against subsequent releases produce evidence that decays the moment the next firmware ships. The standard expects the per-CR evidence to be refreshed against the as-shipped firmware build, with the regression test record carrying the per-release outcomes.
- Component data sheet that overclaims against the assessment record. Suppliers that publish marketing-side component security data sheets making capability claims the per-CR test report does not support produce a credibility gap the procurement-side technical evaluation discovers during evaluation. The data sheet content should be a derivative of the per-CR capability matrix and the test report, not a parallel marketing document.
- No paired 62443-4-1 SDL evidence. Components shipped with strong 62443-4-2 evidence and no paired 62443-4-1 SDL evidence produce a 4-2 claim with no defensible answer to the question "how was this evidence produced". The two standards are paired: 4-1 evidences the discipline that produces the 4-2 evidence. Programmes that operate the two together produce defensible evidence packs for both.
How IEC 62443-4-2 relates to adjacent regimes
IEC 62443-4-2 sits inside a busy OT, product-security, and conformity-assessment neighbourhood. The relationships below are the ones programmes encounter most often when they read 4-2 against the rest of the operating regime. Suppliers shipping across regions and sectors use 62443-4-2 as the per-component capability reference and read 62443-4-1, 62443-3-3, the wider 62443 family, the EU Cyber Resilience Act, Common Criteria, and sector regulations as the contextual layers around it.
IEC 62443-4-2 vs IEC 62443-4-1
IEC 62443-4-2 is the technical side: the per-component requirements the component itself must meet at each Security Level (organised under the seven foundational requirements). IEC 62443-4-1 is the process side: how the supplier develops, ships, and maintains the component securely (the eight SDL practices). Programmes pair them: 4-2 evidences the component meets the requirements, 4-1 evidences the SDL was applied. ISASecure CSA or EDSA certifies 4-2; ISASecure SDLA certifies 4-1. Suppliers seeking both produce two distinct evidence packs that read against each other on the same product record.
IEC 62443-4-2 vs IEC 62443-3-3
IEC 62443-3-3 lists the system-level security requirements (SRs and Requirement Enhancements) that a complete control system must meet at each Security Level. IEC 62443-4-2 lists the corresponding component-level requirements (CRs) for the components inside that system. The two read against each other: a control system claim at SL 3 on FR 1 (3-3 side) reads against the component CR 1.x evidence at SL 3 (4-2 side) for every component the system depends on for that capability. System integrators reading 62443-2-4 read both standards together when assembling the system-level evidence pack.
IEC 62443-4-2 vs the wider 62443 family
The wider IEC 62443 family covers the operating environment around the component. IEC 62443-2-1 is the asset owner cybersecurity management system. IEC 62443-2-3 is patch management between asset owners and product suppliers. IEC 62443-2-4 is the system integrator security programme. IEC 62443-3-2 is the security risk assessment for system design (where the asset owner sets the SL-T per zone the 4-2 components will be deployed into). The 4-2 component evidence enables the rest of the family to operate against a defensible per-component baseline. The component data sheet is the structural input the 3-2 risk assessment reads against component capability.
IEC 62443-4-2 vs the EU Cyber Resilience Act
The EU Cyber Resilience Act (CRA) imposes essential cybersecurity requirements on products with digital elements placed on the EU market, including industrial automation and control system components. The CRA references international standards as the conformity assessment route, and 62443-4-2 is one of the standards manufacturers can read against for the per-component technical security requirements (authentication, access control, secure configuration, data confidentiality and integrity, audit and event capture, secure update). Suppliers preparing for CRA compliance often pair the 4-1 SDL evidence and the 4-2 component evidence into one conformity assessment dossier that reads against the CRA, the ISASecure assessment, and customer-side security reviews simultaneously.
IEC 62443-4-2 vs Common Criteria (ISO/IEC 15408)
Common Criteria evaluates information technology products against a Protection Profile and a Target of Security (Evaluation Assurance Levels EAL 1 to EAL 7). IEC 62443-4-2 evaluates industrial automation and control system components against the foundational requirements (Security Levels SL 1 to SL 4). The two regimes overlap on cryptographic protection, identification and authentication, and audit capture but differ structurally: Common Criteria emphasises the assurance gained from the depth of evaluation; 62443-4-2 emphasises the per-FR capability evidence against the OT-specific operating environment. Components shipping into both regulated IT and OT markets often produce parallel evidence packs.
IEC 62443-4-2 vs UNECE R155 (automotive cybersecurity)
UNECE R155 is the UN-level regulation for automotive cybersecurity management systems (paired with ISO/SAE 21434 on the engineering side). IEC 62443-4-2 is the component-level security requirements standard for industrial automation. The two target different industries and different regulatory environments but share structural heritage on per-component security capability evidence. Suppliers shipping into both industrial and automotive markets often build one component security capability matrix that reads against both sets of requirements, with the per-regulation evidence pack derived from the same underlying capability matrix.
Where SecPortal fits in an IEC 62443-4-2 programme
SecPortal is the operating layer for the component evidence lifecycle, not a replacement for the product security programme strategy, the engineering accountability for the component design and implementation, the ISASecure assessor relationship, or the regulator dialogue the standard expects. The platform handles the 4-2-side workstreams (component scope declaration, per-CR capability matrix, Requirement Enhancement evidence records, per-CR test reports, vulnerability handling cross-reference, secure configuration baseline, end-of- life record, customer-facing component security data sheet) so the artefacts the standard expects are produced as structured records rather than reconstructed across email threads, document drives, and ticketing systems at certification time. The same workspace that hosts the component evidence record hosts the security finding record, the code-scan evidence, and the continuous monitoring of any IT-side supplier portals that touch the component update channel.
- Engagement management dedicated to the 62443-4-2 evidence lifecycle, with one engagement record per component family (or per component where appropriate) so the component scope declaration, the per-CR capability matrix, the Requirement Enhancement evidence record, the per-CR test report, the vulnerability handling cross-reference, the secure configuration baseline, the end-of-life record, and the customer-facing component security data sheet all sit on one structured record rather than being stitched together at certification time.
- Code scanning (SAST and SCA via GitHub, GitLab, and Bitbucket OAuth) that runs against the component source repository so the CR 3.x system integrity claims (input validation, error handling, deterministic output, software and firmware update authenticity) and the FR 4 data confidentiality claims read against verifiable code-side evidence rather than against a self-attestation. SAST findings tie to the affected file and CWE; SCA findings tie to the affected dependency, version, and known CVE. The scan evidence and the per-CR capability matrix join on the operating workspace.
- Findings management with structured records, CVSS 3.1 scoring, CWE tagging, and per-finding asset binding so the per-CR test report, the vulnerability handling cross-reference, and the post-release vulnerability disclosure record all read against the same operating record. Per-firmware-version impact, per-SKU affected list, per-CR claim affected, and per-customer notification reference all sit on the structured finding record rather than on a parallel spreadsheet.
- Document management with versioning for the component scope declaration, the per-CR capability matrix, the Requirement Enhancement evidence records, the per-CR test reports, the secure configuration baseline document, the end-of-life record, the customer-facing component security data sheet, and the regulatory disclosure correspondence. Version history per artefact lets the certification assessor (ISASecure CSA or EDSA), the customer-side procurement technical evaluation, and the regulator reconstruct the artefact set at any point in the component lifecycle.
- AI report generation that turns the structured component evidence record into the leadership-read component certification readiness summary, the per-CR capability matrix narrative for the customer procurement security review, the component security data sheet (drawn from the per-CR capability matrix rather than from a parallel marketing document), and the CRA conformity assessment dossier draft, working against the structured operating record rather than against unstructured email content.
- Activity log with CSV export that captures every state change on the component evidence record (component scope updated, CR capability updated, RE evidence added, test report executed, vulnerability handling cross-reference updated, secure configuration baseline refreshed, end-of-life record updated, customer-facing data sheet republished). The activity log is the audit trail the certification assessor, the regulator, and counsel can reconstruct the component evidence timeline from without a multi-team excavation.
- Retesting workflows that walk the per-CR regression testing across firmware releases, the per-FR re-execution discipline, and the per-RE re-verification at the higher Security Levels so the component evidence does not decay between releases. The retest record carries the per-CR outcome, the per-finding closure trail, and the activity log entry that ties the regression evidence to the component operating record.
- Role-based access control (owner, admin, member, viewer, billing) that keeps the component security programme owner, the security engineering team, the product engineering team, the AppSec team, the GRC team, the customer-facing technical writers producing the component security data sheet, and external ISASecure assessors on one workspace with appropriate per-role scoping. MFA enforcement on accounts that touch the component evidence record so the audit trail is identity-grounded for certification assessment and regulatory inquiry.
- Finding overrides with the eight-field structured exception decision chain (description, justification, compensating control, approved-by, approved-on, expiry-date, conditions, review cadence) so the per-CR partial-conformance dispositions, the SAST and SCA suppressions on CR 3.x evidence, and the customer-side accepted-residual-risk records for CRs the component does not meet carry the same audit-grade decision shape as the broader security exception register. Named approvers, dated decisions, and renewal cadences read against the component operating record at the next certification assessment.
- Compliance tracking that reads the same component evidence pack across IEC 62443-4-2, IEC 62443-4-1 (the paired SDL companion), IEC 62443-3-3 (the system-level requirements the component evidence feeds), the wider 62443 family, the EU Cyber Resilience Act conformity assessment, the Common Criteria evaluation where applicable, the UNECE R155 evidence for cross-shippers into automotive, and sector-specific device cybersecurity guidance, so the cross-regime read is reconcilable rather than reconciled per certification cycle.
- Continuous monitoring schedules (daily, weekly, biweekly, monthly) so the component evidence stays current between certification cycles: re-running SCA against the component dependency graph, re-running SAST against the current source tree, re-running external posture checks against any IT-side supplier portals that touch the component update channel, with the verification evidence attached to the component operating record so the certification assessor reads against the live posture rather than against the assessment-cycle snapshot.
Honest scope for OT product suppliers: SecPortal does not certify components, does not act as a notified body, does not issue ISASecure CSA, ISASecure EDSA, or 62443-4-2 conformity statements, does not replace the supplier accountability for the component capability evidence, does not ship runtime detection or runtime integrity verification for control system components, does not auto-deploy security updates to deployed assets, and does not integrate natively with named ticketing systems (Jira, ServiceNow, Slack, Teams), SIEM platforms, SOAR platforms, GRC platforms (OneTrust, Vanta, Drata, Archer, AuditBoard), or PLM systems. SecPortal also does not provide enterprise SSO or SCIM provisioning, does not perform automated approval routing for component certification gates, and does not maintain component certification customer logos, adoption metrics, ROI numbers, compliance guarantees, or any claim of pre-approved ISASecure CSA, EDSA, or 62443-4-2 conformity. The verified capability stack covers the evidence-record discipline the standard expects across the seven FRs; the certification path remains an exercise between the supplier, the assessor, and the regulator.
The 4-2 component evidence (component scope declaration, per-CR capability matrix, Requirement Enhancement evidence records, per-CR test reports, vulnerability handling cross-reference, secure configuration baseline, end-of-life record, customer-facing component security data sheet) reads against operational workflows that already exist as named use cases. The SDLC vulnerability handoff workflow carries the per-finding handoff discipline the per-CR test report produces. The PSIRT workflow carries the security-issue handling backlog the vulnerability handling cross-reference feeds. The SBOM and VEX publishing workflow carries the per-component component-transparency record the CR 3.x system integrity claims and FR 6 timely response claims reference. The audit fieldwork evidence request workflow carries the ISASecure assessment fieldwork-day evidence packaging the per-CR capability matrix feeds.
For product security teams operating the per-component capability evidence alongside the wider application security programme, the product security teams workspace covers the component evidence operating model and the cross-team handoff the standard expects. For AppSec teams whose remit spans IT and OT product lines, the AppSec teams workspace bundles the platform with the engagement structure the component capability matrix reads against. For internal security teams at OT product supplier organisations carrying the programme-level accountability for the component evidence and the regulatory disclosure obligation under the EU Cyber Resilience Act, the internal security teams workspace covers the platform-level reporting and the cross-team handoff the component operating record sits on. For manufacturing security teams operating across both the IT-side enterprise and the OT-side product programme, the manufacturing security teams workspace covers the joint operating model 62443-4-2 reads against. For CISOs and security leaders accountable for the component security claim posture and the named-decision accountability for product security data sheet content, the CISOs and security leaders workspace covers the executive-layer reporting model that sits on top of the component evidence record.
For deeper reading on the disciplines this standard reads against, the IEC 62443 family overview covers the wider standard and the asset-owner, integrator, and supplier role split that 4-2 sits inside. The IEC 62443-4-1 framework page covers the process-side companion that pairs with 4-2 on the same product evidence record. The EU Cyber Resilience Act framework page covers the EU regulation that increasingly references 62443-4-2 as a conformity assessment anchor for products with digital elements placed on the EU market. The NIST SP 800-82 framework page covers the US federal OT cybersecurity guide that pairs with 62443-4-2 on the asset-owner-side deployment of the component into the operating environment. The container image signing operating model guide covers the secure software delivery discipline that the CR 3.x firmware update authenticity requirements reference. The software bill of materials guide covers the SBOM discipline that the CR 3.x integrity and FR 6 timely response requirements reference for component transparency and security update qualification.
Key control areas
SecPortal helps you track and manage compliance across these domains.
FR 1: Identification and Authentication Control (IAC)
CR 1.1 through CR 1.14 cover human user identification and authentication, software process and device identification and authentication, account management, identifier management, authenticator management, wireless access authentication, strength of public key authentication, authenticator feedback, unsuccessful login attempts, system use notification, access via untrusted networks, strength of password-based authentication, and identification and authentication for guest users. Requirement Enhancements at higher Security Levels add multifactor authentication for human users, public-key infrastructure, and stronger authenticator feedback obfuscation. The CR set establishes who or what the component permits access to perform any subsequent action.
FR 2: Use Control (UC)
CR 2.1 through CR 2.13 cover authorisation enforcement, wireless use control, use control for portable and mobile devices, mobile code restriction, session lock, session termination, concurrent session control, auditable events, audit storage capacity, response to audit processing failures, timestamps, non-repudiation, and use of physical diagnostic and test interfaces. The CR set constrains what an authenticated identity is permitted to do on the component. Higher Security Levels add finer-grained authorisation, more rigorous session controls, and stronger physical interface protections that resist privileged-engineer abuse.
FR 3: System Integrity (SI)
CR 3.1 through CR 3.14 cover communication integrity, malicious code protection (on host and embedded devices where applicable), security functionality verification, software and information integrity, input validation, deterministic output, error handling, session integrity, protection of audit information, software and firmware update authenticity (signed update verification at receive), use of physical diagnostic and test interfaces, and integrity check on the boot process. The CR set protects the integrity of the component, its data, and the communication channels it participates in. Higher Security Levels add stronger cryptographic protections and runtime integrity verification.
FR 4: Data Confidentiality (DC)
CR 4.1 through CR 4.3 cover information confidentiality, information persistence (residual data on persistent storage and decommissioning), and use of cryptography (algorithm and key length expectations, key management). Component type matters: embedded devices with constrained compute carry tailored cryptography expectations; host devices and software applications carry fuller expectations. Higher Security Levels expect stronger algorithms (current rather than legacy primitives), stronger key management (HSM-rooted key storage where applicable), and confidentiality protection across more component interfaces.
FR 5: Restricted Data Flow (RDF)
CR 5.1 through CR 5.4 cover network segmentation support, zone boundary protection, general purpose person-to-person communication restrictions, and application partitioning. The CR set is most consequential for network devices, gateways, and firewalls, where the boundary protection capability the component offers shapes the zone-and-conduit architecture the asset owner builds around it under IEC 62443-3-2. Higher Security Levels expect richer per-conduit policy enforcement and stronger isolation between trust zones.
FR 6: Timely Response to Events (TRE)
CR 6.1 through CR 6.2 cover audit log accessibility (the asset owner side reading audit content off the component) and continuous monitoring (the component participating in the asset-owner-side monitoring discipline). The CR set reads against the operating-environment expectations under IEC 62443-2-1 and the asset-owner-side patch management cadence under IEC 62443-2-3. Higher Security Levels expect richer audit content, more reliable log delivery to the asset-owner-side SIEM or log aggregator, and stronger tamper-evidence on the audit trail.
FR 7: Resource Availability (RA)
CR 7.1 through CR 7.8 cover denial-of-service protection, resource management, control system backup, control system recovery and reconstitution, emergency power, network and security configuration settings, least functionality, and control system component inventory. The CR set protects the availability of essential component functions under load, fault, or attack conditions. Availability is the foundational requirement most distinct from typical IT security regimes, reflecting the operational-technology priority on continuous safe operation through degraded conditions.
Related features
Find vulnerabilities before they ship
Vulnerability management software that tracks every finding
Orchestrate every security engagement from start to finish
Document management for every security engagement
Compliance tracking without a full GRC platform
Verify fixes and track reopens on the same finding record
Every action recorded across the workspace
AI-powered reports in seconds, not days
Test web apps behind the login
Repository connections for SAST and SCA
Role-based access control with least privilege by default
Finding overrides that survive every scan cycle
Run an IEC 62443-4-2-aligned component capability programme on one record
Hold the component scope declaration, the per-CR capability matrix, the Requirement Enhancement evidence records, the per-CR test reports, the vulnerability handling cross-reference, the secure configuration baseline, the end-of-life record, and the customer-facing component security data sheet on one workspace, then read the same record across IEC 62443-4-2, IEC 62443-4-1, IEC 62443-3-3, the wider 62443 family, NIST SP 800-82, and the EU Cyber Resilience Act. Start free.
No credit card required. Free plan available forever.