ISA/IEC 62443 Compliance Capability Mapping - Binarly Transparency Platform

ISA/IEC 62443 is the international standard series for cybersecurity in Industrial Automation and Control Systems (IACS). This document maps Binarly Transparency Platform (BTP) capabilities to the standard parts relevant to product manufacturers, system integrators/service providers, and asset owners operating in OT/ICS environments.

This mapping covers BTP’s direct analytical and reporting capabilities. ISA/IEC 62443 compliance requires organizational, operational, and network-level controls that extend beyond binary analysis tooling. Where BTP provides supporting evidence rather than full coverage, this is explicitly noted.

Applicable Standard Parts

BTP maps to four standard parts across three distinct ISA/IEC 62443 stakeholder roles:

Persona	Standard Parts
Manufacturers / Product Suppliers	62443-4-1 (SDL), 62443-4-2 (Component Requirements)
System Integrators / Service Providers	62443-2-4 (Service Provider Program), 62443-3-3 (System Requirements)
Asset Owners	62443-2-1 (Asset Owner Program), 62443-2-3 (Patch Management), 62443-3-3 (System Requirements)

Standard Part	Title	BTP Relevance
IEC 62443-4-1	Secure Product Development Lifecycle Requirements	Primary — BTP supports all 8 SDL practices as a binary verification layer
IEC 62443-4-2	Technical Security Requirements for IACS Components	Primary — BTP verifies component-level security posture
IEC 62443-2-3	Patch Management in the IACS Environment (TR)	Primary — SBOM + VEX enable patch applicability assessment
IEC 62443-2-4	Security Program Requirements for IACS Service Providers	Primary — BTP enables independent third-party binary verification
IEC 62443-3-3	System Security Requirements and Security Levels	Primary — BTP provides SL-3/SL-4 assurance evidence for system-level SRs
IEC 62443-2-1	Security Program Requirements for IACS Asset Owners	Supporting — BTP evidence supports risk-based procurement and continuous compliance

Parts 62443-1-x (general terminology), 62443-3-2 (risk assessment methodology), and 62443-3-1 (security technologies TR) address foundational and organizational requirements that are outside BTP’s analytical scope.

Coverage Summary

Coverage levels: Full — BTP directly addresses the requirement. Partial — BTP addresses specific aspects; additional controls required. Evidence — BTP produces artifacts that support compliance evidence; implementation is outside BTP’s scope. Not Covered — Outside BTP’s analytical scope.

Requirement Area	Standard Reference	BTP Coverage
Third-party component inventory (SBOM)	62443-4-1 Practice 2	Full
Binary integrity verification	62443-4-1 Practice 4 / 62443-4-2 CR 3.4	Full
Unsafe function / prohibited API detection	62443-4-1 Practice 4	Full
Binary hardening verification (ASLR, stack canaries, NX, PIE, RELRO, CFI)	62443-4-1 Practice 3 / 62443-4-2 CR 3.x	Full
Security verification & vulnerability testing	62443-4-1 Practice 5	Full
CVE tracking and vulnerability disclosure	62443-4-1 Practice 6	Full
Patch status communication (VEX)	62443-4-1 Practice 7 / 62443-2-3	Full
Cryptographic material inventory (CBOM)	62443-4-2 FR 4 (DC) / 62443-4-1 Practice 2	Full
Weak / non-compliant cryptography detection	62443-4-2 CR 4.1–4.3	Full
Post-quantum cryptography readiness	62443-4-2 FR 4 (future)	Full
Supply chain integrity and tampering detection	62443-4-1 Practice 2 / FR 3 (SI)	Partial
Vulnerability exploitability assessment (Reachability)	62443-4-2 FR 3 (SI) / 62443-2-3	Full
CISA KEV-tracked vulnerability prioritization	62443-2-3	Full
Cross-image patch regression tracking	62443-4-1 Practice 7 / 62443-2-3	Full
Malicious code detection	62443-4-2 FR 3 (SI)	Full
Suspicious code and obfuscation detection	62443-4-2 FR 3 (SI)	Full
UEFI / firmware-specific vulnerability classes	62443-4-2 EDR requirements	Full
Hardcoded credential and secret detection	62443-4-2 FR 1 (IAC)	Partial
Access control enforcement	62443-4-2 FR 2 (UC)	Evidence
Network segmentation and data flow control	62443-4-2 FR 5 (RDF)	Not Covered
Vulnerability intelligence for incident response (VEX, CISA KEV, reachability)	62443-4-2 FR 6 (TRE)	Partial
Patching downtime reduction via reachability prioritization	62443-4-2 FR 7 (RA)	Partial
Third-party binary malware verification (SP.03.02)	62443-2-4	Full
Third-party CVE monitoring incl. undisclosed dependencies (SP.09.01)	62443-2-4	Full
SL-3/SL-4 malicious code protection (SR 3.2)	62443-3-3	Full
Binary configuration and hardening verification (SR 7.6)	62443-3-3	Partial
Risk-based procurement via binary SBOM delta	62443-2-1	Evidence
Continuous compliance verification before OT deployment	62443-2-1	Evidence

IEC 62443-4-1: Secure Product Development Lifecycle

IEC 62443-4-1 defines 8 SDL practices that product suppliers must implement. BTP supports all 8 practices as a binary verification layer in the development pipeline.

Practice 1 — Security Management

Requirement: Security governance, policy, organizational roles, and SDL support infrastructure.BTP Support (Evidence):

BTP enforces RBAC with granular roles across organization, product, and image scopes, supporting separation of duties requirements.
SSO (SAML/OIDC) and mandatory MFA enforce identity governance requirements.
SOC 2 Type 2 certification (available at trust.binarly.io) provides independent third-party attestation of BTP’s security controls.
On-premises deployment option (Binarly v3) supports air-gapped or isolated environments required for sensitive ICS product development.
API-driven CI/CD integration supports systematic SDL enforcement rather than ad-hoc scanning.

Gaps: Organizational policy authoring, governance documentation, and role assignment workflows are outside BTP’s scope.

Practice 2 — Security Requirements Specification

Requirement: Threat modeling, product security requirements, third-party and open-source component security requirements including component inventory.BTP Support (Full):BTP directly addresses the component inventory and third-party risk requirements that 62443-4-1 Practice 2 mandates:

Binary-derived SBOM (CycloneDX and SPDX): generated from actual compiled binaries rather than vendor-declared manifests, revealing components regardless of documentation accuracy. This satisfies the component inventory obligation for downstream integrators and asset owners.
CBOM (CycloneDX): cryptographic material inventory of every algorithm, protocol, key, and certificate in the binary, used to assess cryptographic security requirements (FR 4).
Transitive dependency tracking: 8 linkage types (direct, static, dynamic, build, derived, vendored, project, unspecified) provide full traceability of how third-party components are incorporated.
Dependency vulnerability mapping: CVE exposure for all detected components including nested transitive dependencies.

The binary-derived approach matters for 62443 compliance: declared SBOMs from vendors frequently omit components. BTP’s ground-truth analysis closes this gap.

Artifact	Format	Relevant 62443-4-1 Requirement
SBOM	CycloneDX, SPDX	Maintain software component inventory; assess third-party component security requirements
CBOM	CycloneDX	Identify cryptographic requirements for all dependencies
Findings Report	PDF, JSON, CSV	Document security issues from third-party and open-source dependencies

Practice 3 — Secure by Design

Requirement: Secure architecture, attack surface reduction, least privilege by design, design-level security controls.BTP Support (Full for verification; Evidence for design):BTP verifies that secure-by-design requirements were actually implemented in the binary:Binary hardening verification — detects missing mitigations that represent design failures:

Mitigation	Finding Class	Architecture
Stack canary / SSP	`mitigation/missing-stack-canaries`	POSIX
ASLR / PIE	`mitigation/posix/pie-disabled`	POSIX
NX / DEP	`mitigation/posix/nx-disabled`	POSIX
RELRO	`mitigation/posix/relro-disabled`	POSIX
Fortify Source	`mitigation/posix/fortify-source-disabled`	POSIX
Control Flow Integrity	`mitigation/missing-control-flow-integrity`	POSIX / UEFI
UEFI Memory Protection	`mitigation/uefi/memory-protection-misconfiguration`	UEFI
Microcode updates	`mitigation/uefi/outdated-intel-microcode-version`	UEFI

A component that fails these checks does not meet the secure-by-design baseline for its target Security Level.Attack surface indicators:

Unstripped binaries exposing symbol information (weakness/posix/not-stripped)
RPATH issues enabling library injection attacks (weakness/posix/rpath-set)
Linux kernel hardening configuration findings (weakness/linux/kernel-configuration)

Practice 4 — Secure Implementation

Requirement: Secure coding guidelines, prohibited function lists, static analysis (SAST), and code review.BTP Support (Full):BTP performs binary-level static analysis equivalent to post-compilation SAST — detecting implementation failures that survive code review:Prohibited/unsafe function detection:

weakness/posix/unsafe-functions/summary: detects use of strcpy, sprintf, gets, and other functions prohibited by secure coding standards (CERT C, MISRA)
Unsafe function usage maps directly to the “prohibited functions list” requirement in 62443-4-1 Practice 4

Binary analysis capabilities:

Compiled binary analysis catches issues that source-level SAST misses (inlined functions, LTO artifacts, compiler-introduced patterns)
Works without access to source code — critical for third-party component verification
Supports architectures used in IACS: x86, ARM32/64, Xtensa

Firmware-specific implementation checks:

UEFI SMM handler vulnerabilities: SMRAM corruption, SMM callouts, unsafe pointer dereferences
Malicious or suspicious code patterns: packed ELF, code obfuscation, ifuncs abuse, PT_NOTE conversion to PT_LOAD

BTP integrates into CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, bash) to enforce these checks at every build.

Practice 5 — Security Verification and Validation Testing

Requirement: Security test plans, penetration testing, fuzz testing, dynamic analysis (DAST), regression testing.BTP Support (Full for binary V&V; Evidence for active testing):BTP provides binary-level verification and validation that complements active testing:Vulnerability verification:

Known vulnerability detection (CVE-mapped) with confidence scoring derived from detection method reliability
Unknown vulnerability detection via FwHunt/VulHunt rules for zero-day class vulnerabilities in UEFI, BMC, and embedded firmware

Reachability Analysis — exploitability contextualization:BTP’s Reachability Analysis provides four-tier exploitability classification, directly addressing the 62443-4-1 requirement to assess whether identified vulnerabilities are exploitable in the product context:

Reachability Tier	Exploitability Assessment	V&V Relevance
Direct	Reachable from main/entry-point	Highest priority for V&V
Exported	Reachable from exported interfaces	High — exploitable from component boundary
Referenced	Reachable via code references	Medium — requires component interaction
Undetermined	Cannot be statically determined	Requires dynamic testing to resolve

Undetermined reachability findings show where active penetration testing or fuzz testing is needed to resolve exploitability.Regression testing support:

Cross-image comparison via the Compare feature and the Compare Findings API tracks security regressions between builds to confirm previously remediated vulnerabilities have not been reintroduced.

Practice 6 — Management of Security-Related Issues

Requirement: Vulnerability disclosure policy, defect tracking, CVE management.BTP Support (Full):VEX generation is BTP’s primary contribution to Practice 6. VEX (Vulnerability Exploitability eXchange) encodes per-CVE exploitability decisions in machine-readable format:

VEX Status	Meaning	62443-4-1 Practice 6 Use
`affected`	Vulnerability is exploitable in this component	Triggers remediation workflow
`not_affected`	Vulnerability is not exploitable (with justification)	Closes false-positive tracking
`fixed`	Patch has been applied	Documents remediation completion
`under_investigation`	Exploitability not yet determined	Documents active triage status

VEX formats supported: OpenVEX, CycloneDX VEX — both CISA-recognized for vulnerability disclosure.CVE management:

CVE-identified findings are tracked at component level with CPE identifiers
CISA Known Exploited Vulnerability (KEV) catalog integration prioritizes findings requiring mandatory remediation per CISA BOD 22-01
Cross-version tracking enables demonstrating remediation to downstream customers

Practice 7 — Security Update Management

Requirement: Patch development, patch distribution documentation, end-of-life policy, patch verification.BTP Support (Full):Patch verification via cross-image comparison:

Scan the patched binary and compare against the pre-patch baseline using the Compare Findings feature
API endpoint: POST /api/v4/grids/findings:gridList with filters for both image IDs provides machine-readable delta output for automated patch verification in release pipelines (see Compare Findings API)

VEX status lifecycle management:

Update VEX status from under_investigation → affected → fixed as patches progress
VEX artifacts accompany firmware update packages to inform downstream asset owners of what was remediated

Patch applicability for asset owners (62443-2-3 integration):

SBOM enables asset owners to determine whether a patched component is present in their deployed systems
VEX with fixed status and component version range data enables patch prioritization without requiring manual analysis

End-of-life component detection:

Dependency findings identify components with known EOL status where the CVE backlog has ceased to be addressed by upstream maintainers

Practice 8 — Security Guidelines

Requirement: Product security documentation for integrators and asset owners, hardening guides.BTP Support (Full for artifact generation; Evidence for authoring):BTP generates the technical artifacts included in security guideline packages delivered with IACS components:

Artifact	Content	Security Guideline Use
SBOM (CycloneDX / SPDX)	Complete software component inventory	Enables asset owners to assess CVE exposure in their deployment
CBOM (CycloneDX)	Cryptographic algorithm, key, certificate inventory	Informs cryptographic configuration guidance and PQC migration planning
VEX (OpenVEX / CycloneDX)	Vulnerability exploitability status	Documents known vulnerability handling for integrators
PQC Compliance Report (PDF / JSON)	NIST-aligned post-quantum readiness assessment	Executive summary + algorithm migration timeline for customers
Findings Report (PDF / JSON / CSV)	Full security posture with severity and confidence	Hardening guidance evidence package for integrators

The PQC report matters most for IACS components with 10–20+ year operational lifespans that will outlive current cryptographic standards.

IEC 62443-4-2: Component Security Requirements

IEC 62443-4-2 defines Component Requirements (CRs) for embedded devices (EDR), host devices (HDR), network devices (NDR), and software applications (SAR) across the 7 Foundational Requirements (FRs) at Security Levels 1–4.

FR 1 — Identification and Authentication Control (IAC)

Scope: Unique entity identification, authentication mechanisms, credential management.BTP Coverage: PartialBTP detects credential and authentication failures embedded in firmware, but does not enforce authentication policy at runtime.Directly detected violations:

Finding Class	CR Violation	Description
`secret/credentials`	CR 1.5 — Authenticator management	Hardcoded usernames and passwords in binary
`secret/api-credentials`	CR 1.5	Hardcoded API keys and service credentials
`secret/private-key`	CR 1.5	Embedded private keys that compromise PKI-based authentication
`secret/leaked`	CR 1.5	Credentials confirmed active/valid via external validation
`secret/oauth-token`	CR 1.5	OAuth and JWT tokens embedded in firmware
`crypto/certificate-expired`	CR 1.8 — PKI certificates	Expired authentication certificates
`crypto/certificate-self-signed`	CR 1.8	Self-signed certificates bypassing trust chain
`crypto/certificate-untrusted-root`	CR 1.8	Certificates not anchored to trusted roots
`crypto/weak-rsa-parameters`	CR 1.8	RSA keys below minimum strength requirements

Gap: Authentication enforcement (IAC at SL 2–4: MFA, hardware tokens, certificate lifecycle management) is a runtime/operational control outside BTP’s scope.

FR 2 — Use Control (UC)

Scope: Least-privilege access control, RBAC enforcement, audit logging of access decisions.BTP Coverage: EvidenceBTP itself implements use control requirements for the platform (RBAC, MFA, SSO), but does not perform automated analysis of access control logic in analyzed binaries.BTP platform-level UC compliance:

Granular RBAC: Admin, Analyst, and Viewer roles scoped to Organization, Product, and Image levels
All access decisions are logged; audit trail is available for compliance review
Mandatory MFA and SSO (SAML/OIDC) enforce authentication before use control is applied

For analyzed components: Use control logic in firmware (privilege separation, permission checking) requires manual review of binary logic or source code analysis. BTP’s reachability analysis can contextualize whether privilege-controlled paths are accessible to untrusted inputs, but automated UC policy verification is not a current BTP capability.

FR 3 — System Integrity (SI)

Scope: Protection of hardware, software, and communications against unauthorized modification; secure boot; firmware integrity; malware protection.BTP Coverage: Full.FR 3 (System Integrity) is the foundational requirement most directly addressed by binary analysis:Secure boot and firmware integrity (EDR 3.4):

UEFI Secure Boot bypass vulnerabilities: vulnerability/uefi/secure-boot-bypass
PKfail and related supply chain compromise of platform keys: supply-chain/pkfail
UEFI boot script vulnerabilities enabling pre-boot compromise
BootGuard policy violations

Firmware integrity verification gaps:

mitigation/missing-control-flow-integrity: Control Flow Integrity absent — enables hijacking of execution after integrity bypass
mitigation/uefi/memory-protection-misconfiguration: UEFI memory protection policies not enforced
weakness/posix/not-stripped: Symbols present, reducing reverse engineering barrier for integrity attacks

Malicious and suspicious code (CR 3.8 — Malware protection):

malware/known-malware: Binary contains signatures matching known malicious firmware implants
malware/uefi-hook-installation: Hooks into UEFI boot services — hallmark of firmware persistence implants
malware/malicious-behavior: Behavioral patterns indicative of malicious intent
suspicious/packed-elf: Binary packing used to evade integrity scanning
suspicious/obfuscated-code: Code obfuscation inconsistent with legitimate firmware
suspicious/reverse-text: Anti-analysis technique indicating potential tampering
suspicious/pt-note-conversion: PT_NOTE to PT_LOAD conversion — common ELF rootkit technique

Communication integrity:

Detection of weak or absent integrity mechanisms in protocol implementations
POSIX and UEFI-level unsafe operations enabling memory corruption attacks against integrity controls

FR 4 — Data Confidentiality (DC)

Scope: Protection of sensitive data at rest and in transit; encryption algorithm requirements; key management.BTP Coverage: Full.The CBOM and cryptographic finding classes cover FR 4 directly:Weak or non-compliant algorithms:

Finding Class	FR 4 Violation
`crypto/weak-hash-algorithm`	Insecure hashing (MD5, SHA-1) for data integrity/confidentiality
`crypto/weak-encryption-algorithm`	DES, 3DES, RC4, or other deprecated ciphers
`crypto/weak-mac-algorithm`	Weak HMAC or MAC constructions
`crypto/deprecated-protocol`	SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1
`crypto/weak-rsa-parameters`	RSA keys below 2048-bit (CR 4.3 minimum)
`crypto/weak-ec-parameters`	EC curves below recommended strength

Certificate and key management (CR 4.2, EDR 4.1):

Finding Class	FR 4 Violation
`crypto/certificate-expired`	Expired TLS/signing certificates
`crypto/certificate-self-signed`	Self-signed certs bypassing trust chain
`crypto/certificate-untrusted-root`	Certificates from non-trusted anchors
`secret/private-key`	Private keys embedded in firmware — catastrophic DC failure
`crypto/pkcs7-weak-signature`	Weakly signed code or data bundles

Post-quantum readiness (CR 4.x for long-lifecycle components): The PQC Compliance Report identifies all cryptographic algorithms vulnerable to quantum attacks (RSA, ECC, Diffie-Hellman, SHA-1/SHA-256 for signatures), providing:

Executive summary with compliance status vs. NIST PQC standards (FIPS 203/204/205)
Per-algorithm migration urgency ratings
Component-level quantum exposure inventory from CBOM

IACS components with 10–20 year operational lifespans will outlive the cryptographic algorithms protecting them today.

FR 5 — Restricted Data Flow (RDF)

Scope: Network segmentation, zone/conduit enforcement, firewall controls, unidirectional gateways.BTP Coverage: Not Covered.FR 5 is a network-architectural control requirement. BTP analyzes firmware and software binaries for security vulnerabilities — it does not perform network traffic analysis, firewall rule validation, or zone/conduit topology verification.Network security tools (firewalls, unidirectional gateways, network monitoring platforms) address FR 5 compliance.Adjacent BTP value: Detection of hardcoded IP addresses and network credentials (secret/credentials) that could undermine intended network segmentation controls.

FR 6 — Timely Response to Events (TRE)

Scope: Security event detection, audit log generation, intrusion detection, incident response.BTP Coverage: Partial — enables TRE but does not provide operational monitoring.BTP generates the vulnerability intelligence that feeds timely response workflows:Direct contribution:

VEX documents with under_investigation and affected status formalize the identification phase of incident response for known vulnerability classes
CISA KEV integration flags findings requiring mandatory 14-day remediation per CISA BOD 22-01
Reachability analysis contextualizes urgency: Direct reachability findings require immediate response; undetermined reachability enables risk-based prioritization

Gap: Audit log generation, SIEM integration, real-time intrusion detection, and incident response orchestration are operational controls outside BTP’s scope. SIEM/SOC platforms address FR 6 for operational environments.

FR 7 — Resource Availability (RA)

Scope: DoS resilience, redundancy, resource usage monitoring, backup and recovery.BTP Coverage: Partial.In OT environments, patching is operationally disruptive — downtime in production systems has direct physical and financial consequences. Unnecessary patching of vulnerabilities that cannot actually be reached is a significant availability risk. BTP’s Reachability Analysis reduces this risk:

Reduces unnecessary patching downtime: By classifying vulnerabilities as Direct, Exported, Referenced, or Undetermined reachability, BTP allows operators to defer patching of unreachable code without compromising the system’s security posture.
DoS-relevant vulnerability isolation: CVSS Availability Impact filtering (CVSS Vector Filtering) isolates findings that directly threaten availability, such as those causing resource exhaustion or service disruption.
Vulnerability classes threatening availability: Missing mitigations (CFI, stack canaries) enable memory corruption attacks weaponizable for DoS; specific CVE classes are flagged with CVSS Impact scores indicating availability impact.

Gap: Operational availability controls — redundant architectures, failover mechanisms, backup/restore procedures, and uptime monitoring — are outside BTP’s analytical scope. Infrastructure and HA platforms address those requirements.

IEC 62443-2-4: Service Provider Requirements

IEC 62443-2-4 defines the security program capabilities that system integrators and service providers must offer when delivering integration and maintenance activities to IACS asset owners. It requires service providers to independently verify that the components they integrate are free from malicious code and continuously monitored for new vulnerabilities — without necessarily having access to vendor source code. Service providers can fulfill these obligations with BTP’s black-box binary analysis:

62443-2-4 Requirement	BTP Capability
SP.03.02 — Malware Protection: Verify that delivered third-party software is free from malicious code and firmware implants	BTP scans any binary image without source code access, detecting firmware backdoors, UEFI implants, supply chain tampering, and suspicious code patterns across all 238 finding classes
SP.09.01 — Vulnerability Monitoring: Maintain continuous monitoring of third-party components for newly disclosed CVEs, including vulnerabilities not disclosed by the original vendor	Binary-derived SBOM reveals statically linked dependencies that vendor manifests routinely omit; BTP maps CVE exposure across all detected components including hidden transitive dependencies
Patch applicability assessment before deployment	SBOM + VEX enable service providers to determine whether a vendor-issued patch applies to their specific integrated configuration before scheduling disruptive maintenance windows
Independent verification of vendor security claims	Binary-derived SBOM delta vs. vendor-declared SBOM surfaces undisclosed components, flagging supply chain risk that vendor self-attestation would not reveal

The core value for 62443-2-4 is the shift from “trust the vendor” to “verify the binary.” Most compliance tooling for service providers relies on vendor-provided SBOMs and self-attestation. BTP converts the opaque binary into an auditable artifact. This enables independent verification that third-party software meets the asset owner’s Target Security Level (SL-T), regardless of vendor claims.

IEC 62443-3-3: System Security Requirements

IEC 62443-3-3 defines 110 system-level Security Requirements (SRs) across the 7 Foundational Requirements at Security Levels 1–4. BTP maps directly to the SRs where binary analysis provides concrete verification evidence, particularly at SL-3 and SL-4 where defense against intentional attacks is required.

SR	Title	BTP Coverage	BTP Capability
SR 3.2	Malicious Code Protection	Full	Semantic malware detection identifies firmware implants, backdoors, and Secure Boot bypasses (e.g., LogoFAIL, PKfail) that signature-based AV misses. Provides the higher assurance level required for SL-3/SL-4, where protection against sophisticated intentional violations is mandated.
SR 7.6	Network and Security Configuration Settings	Partial	BTP extracts configuration metadata from binaries — insecure protocol configurations (SSL/TLS versions, deprecated ciphers), hardening status (RELRO, PIE, NX), and credential artifacts — to verify that third-party software meets the hardening baseline mandated by the system design. Active network configuration enforcement is outside BTP’s scope.
SR 3.4	Software and Information Integrity	Full	Detects integrity violations in firmware binaries: unsigned code, missing CFI, tampered binaries (obfuscated/packed/reversed code), and supply chain compromise artifacts.
SR 1.1 / SR 1.5	Human User Identification / Authenticator Management	Partial	Detects hardcoded credentials, embedded private keys, and expired PKI certificates in system components that violate authentication integrity requirements. Runtime IAC enforcement is outside scope.

SL-3 and SL-4 relevance: At SL-3 (protection against sophisticated attacks with OT-specific knowledge) and SL-4 (protection against state-level APT attacks), SR 3.2 requires going beyond signature-based malware detection. BTP’s semantic analysis — which identifies behavioral patterns, code structure anomalies, and known implant families — meets the depth required at these security levels. Simple AV scanning does not satisfy SL-3/SL-4 for SR 3.2.

IEC 62443-2-3: Patch Management

IEC 62443-2-3 is a Technical Report defining patch management requirements for IACS asset owners and the obligations of product suppliers to support patching activities. BTP supports both product suppliers (demonstrating patch delivery) and asset owners (assessing patch applicability and urgency):

For Product Suppliers

62443-2-3 Requirement	BTP Capability
Maintain component inventory subject to patching	Binary-derived SBOM provides ground-truth component list with versions
Communicate CVE exposure to asset owners	VEX documents communicate `affected` / `fixed` / `not_affected` status per CVE per component version
Verify patch efficacy	Cross-image comparison confirms vulnerability resolution between pre-patch and post-patch builds
Document patch scope	Findings delta report identifies exactly which vulnerabilities were remediated in each release

For Asset Owners

62443-2-3 Requirement	BTP Capability
Assess patch applicability to deployed systems	SBOM enables matching vendor-issued SBOMs against known component inventory
Prioritize patches by exploitability	VEX `affected` status + Reachability tier + CVSS vector filtering enables risk-based prioritization
Prioritize mandatory patches	CISA KEV integration flags actively exploited vulnerabilities requiring mandatory remediation
Document patching decisions	Findings export (PDF / JSON / CSV) provides auditable record of known vulnerabilities and remediation status

Generating ISA/IEC 62443 Compliance Artifacts

BTP generates all standard-required compliance artifacts via API or UI export.

Upload and scan the firmware binary

Upload the firmware image and wait for scan completion. For CI/CD integration, use the CI/CD Integration pipeline.

Generate SBOM (62443-4-1 Practice 2 / 62443-2-3)

curl -H "Authorization: Bearer ${TOKEN}" \
  "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/sbomReport:cycloneDX?contentType=json" \
  -o sbom-cyclonedx.json

# Also available: sbomReport:spdx

Generate CBOM (62443-4-2 FR 4 / DC)

curl -H "Authorization: Bearer ${TOKEN}" \
  "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/cbomReport:cycloneDX" \
  -o cbom-cyclonedx.json

Generate VEX (62443-4-1 Practice 6–7 / 62443-2-3)

curl -H "Authorization: Bearer ${TOKEN}" \
  "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/vexReport:openVEX" \
  -o vex-openvex.json

# Also available: vexReport:cycloneDX

Generate PQC Report (62443-4-2 FR 4 — long-lifecycle components)

# JSON for machine consumption
curl -H "Authorization: Bearer ${TOKEN}" \
  "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/cryptographicMaterialsReport?mode=pqc-compliance&contentType=json" \
  -o pqc-compliance.json

# PDF for human review and audit packages
curl -H "Authorization: Bearer ${TOKEN}" \
  "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/cryptographicMaterialsReport?mode=pqc-compliance&contentType=pdf" \
  -o pqc-compliance.pdf

Export Findings Report (62443-4-1 Practice 5 / 62443-4-2 all FRs)

# Full findings report for audit package
curl -H "Authorization: Bearer ${TOKEN}" \
  "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/findingsReport:pdf?mode=full" \
  -o findings-full.pdf

# Machine-readable for automated compliance gates
curl -H "Authorization: Bearer ${TOKEN}" \
  "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/findingsReport:json" \
  -o findings.json

For a single-command script that downloads all artifacts, see Compliance Artifacts — Automation Script.

Known Limitations

The following ISA/IEC 62443 requirements are outside BTP’s scope as a binary analysis platform:

Do not use BTP as the sole evidence source for these requirement areas. Complementary controls are required to achieve a complete compliance posture.

Requirement Area	Standard Reference	Recommended Approach
Network segmentation, zone/conduit enforcement	FR 5 (RDF)	Industrial firewalls, unidirectional gateways, network security monitoring platforms
Real-time operational event monitoring and SIEM	FR 6 (TRE)	Industrial SIEM, OT-aware IDS (e.g., Claroty, Dragos, Nozomi)
Redundancy, failover, and uptime monitoring	FR 7 (RA) — operational	Infrastructure redundancy design, HA platforms, availability monitoring
Access control enforcement and RBAC in firmware	FR 1/2 (IAC/UC)	Runtime security testing, source code review, penetration testing
Security management policies and governance	62443-4-1 Practice 1	GRC platforms, policy management tools
Threat modeling and security requirements definition	62443-4-1 Practice 2	Threat modeling tools (STRIDE, PASTA), security requirements management
Active penetration testing and fuzz testing	62443-4-1 Practice 5	Dynamic testing tools, dedicated firmware pentest engagements
Organizational patch management workflows	62443-2-3 (procedural)	Vulnerability management platforms, asset owner patch workflows
Service provider governance, contracts, and audit programs	62443-2-4 (non-technical)	Contract requirements, service provider audit programs, GRC platforms
Asset owner security program governance	62443-2-1 (non-technical)	GRC platforms, CSMS/Security Program management tools

SBOM Export

Generate binary-derived Software Bills of Materials in CycloneDX and SPDX formats.

CBOM Export

Inventory all cryptographic algorithms, keys, and certificates in analyzed binaries.

VEX Export

Communicate vulnerability exploitability status to downstream integrators and asset owners.

PQC Compliance Report

Assess post-quantum cryptography readiness for long-lifecycle IACS components.

Reachability Analysis

Understand exploitability context for vulnerability prioritization.

Finding Classes

Complete reference of all 238 finding classes and their security significance.

Deep Dive

Compliance

​Applicable Standard Parts

​Coverage Summary

​IEC 62443-4-1: Secure Product Development Lifecycle

​IEC 62443-4-2: Component Security Requirements

​IEC 62443-2-4: Service Provider Requirements

​IEC 62443-3-3: System Security Requirements

​IEC 62443-2-3: Patch Management

​For Product Suppliers

​For Asset Owners

​Generating ISA/IEC 62443 Compliance Artifacts

​Known Limitations

​Related Documentation

SBOM Export

CBOM Export

VEX Export

PQC Compliance Report

Reachability Analysis

Finding Classes

Applicable Standard Parts

Coverage Summary

IEC 62443-4-1: Secure Product Development Lifecycle

IEC 62443-4-2: Component Security Requirements

IEC 62443-2-4: Service Provider Requirements

IEC 62443-3-3: System Security Requirements

IEC 62443-2-3: Patch Management

For Product Suppliers

For Asset Owners

Generating ISA/IEC 62443 Compliance Artifacts

Known Limitations

Related Documentation