IEC 62443-4-2:2019 — Technical security requirements for IACS components
Part 4-2 defines technical security requirements for IACS components using the foundational requirements and security-level framework.
What the authority record establishes
Part 4-2 defines technical security requirements for IACS components using the foundational requirements and security-level framework.
Not law by itself
The exact official title, issuing body, jurisdiction, version or application record, and linked source define the scope of this page. Readers should not transfer the authority's status to a commercial product or infer transaction-, patient-, system-, site-, or organization-specific applicability from this summary.
Why it matters to this market
Component claims should identify exact product, version, certification scheme, target level, and system dependency.
Affected operating stages
- Component Requirements
- Product Selection
- Integration
- Verification
- Maintenance
Capabilities to examine
Privileged Access, Credential, And Identity Governance
Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for privileged access, credential, and identity governance.
Configuration, Baseline, And Change Monitoring
Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for configuration, baseline, and change monitoring.
Endpoint Allowlisting And Malware Prevention
Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for endpoint allowlisting and malware prevention.
Firmware, SBOM, And Component Intelligence
Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for firmware, SBOM, and component intelligence.
Compliance Mapping And Control Evidence
Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for compliance mapping and control evidence.
Device And Product Software-Supply-Chain Risk
Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for device and product software-supply-chain risk.
Affected buyer audiences
- component suppliers
- integrators
- asset owners
- product-security teams
Implementation questions
- Which entities, products, populations, transactions, systems, sites, or jurisdictions are actually within scope?
- What is binding, what is guidance, and what is a technical or consensus standard?
- Which publication, adoption, effective, application, transition, and enforcement dates differ?
- Who owns legal, clinical, quality, regulatory, policy, or operational interpretation?
- How will a source revision affect open work and historical decisions?
Interpretation boundary
Component conformance does not establish installed-system conformance, secure integration, or operational suitability.