> ## Documentation Index
> Fetch the complete documentation index at: https://docs.binarly.io/llms.txt
> Use this file to discover all available pages before exploring further.

# ISA/IEC 62443 Compliance Capability Mapping

> How the Binarly Transparency Platform maps to ISA/IEC 62443 industrial cybersecurity requirements for firmware and software component security.

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.

<Note>
  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.
</Note>

***

## 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

<Note>
  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.
</Note>

| 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.

<AccordionGroup>
  <Accordion title="Practice 1 — Security Management" icon="shield-halved">
    **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.
  </Accordion>

  <Accordion title="Practice 2 — Security Requirements Specification" icon="list-check">
    **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                    |
  </Accordion>

  <Accordion title="Practice 3 — Secure by Design" icon="pen-ruler">
    **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`)
  </Accordion>

  <Accordion title="Practice 4 — Secure Implementation" icon="code">
    **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.
  </Accordion>

  <Accordion title="Practice 5 — Security Verification and Validation Testing" icon="flask">
    **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](/resource-center/reachability) 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](/user-guides/image-scans/compare) feature and the [Compare Findings API](/api-reference/finding/compare-findings) tracks security regressions between builds to confirm previously remediated vulnerabilities have not been reintroduced.
  </Accordion>

  <Accordion title="Practice 6 — Management of Security-Related Issues" icon="triangle-exclamation">
    **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
  </Accordion>

  <Accordion title="Practice 7 — Security Update Management" icon="arrow-rotate-right">
    **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](/api-reference/finding/compare-findings))

    **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
  </Accordion>

  <Accordion title="Practice 8 — Security Guidelines" icon="book">
    **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.
  </Accordion>
</AccordionGroup>

***

## 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.

<AccordionGroup>
  <Accordion title="FR 1 — Identification and Authentication Control (IAC)" icon="fingerprint">
    **Scope:** Unique entity identification, authentication mechanisms, credential management.

    **BTP Coverage: Partial**

    BTP 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/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.
  </Accordion>

  <Accordion title="FR 2 — Use Control (UC)" icon="lock">
    **Scope:** Least-privilege access control, RBAC enforcement, audit logging of access decisions.

    **BTP Coverage: Evidence**

    BTP 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.
  </Accordion>

  <Accordion title="FR 3 — System Integrity (SI)" icon="shield-check">
    **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
  </Accordion>

  <Accordion title="FR 4 — Data Confidentiality (DC)" icon="eye-slash">
    **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.
  </Accordion>

  <Accordion title="FR 5 — Restricted Data Flow (RDF)" icon="network-wired">
    **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.
  </Accordion>

  <Accordion title="FR 6 — Timely Response to Events (TRE)" icon="bell">
    **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.
  </Accordion>

  <Accordion title="FR 7 — Resource Availability (RA)" icon="server">
    **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](/resource-center/reachability) 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](/user-guides/image-scans/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.
  </Accordion>
</AccordionGroup>

***

## 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                                   |

<Note>
  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.
</Note>

***

## 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.

<Steps>
  <Step title="Upload and scan the firmware binary">
    Upload the firmware image and wait for scan completion. For CI/CD integration, use the [CI/CD Integration](/api-reference/use-cases/cicd/overview) pipeline.
  </Step>

  <Step title="Generate SBOM (62443-4-1 Practice 2 / 62443-2-3)">
    ```bash theme={null}
    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
    ```
  </Step>

  <Step title="Generate CBOM (62443-4-2 FR 4 / DC)">
    ```bash theme={null}
    curl -H "Authorization: Bearer ${TOKEN}" \
      "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}/cbomReport:cycloneDX" \
      -o cbom-cyclonedx.json
    ```
  </Step>

  <Step title="Generate VEX (62443-4-1 Practice 6–7 / 62443-2-3)">
    ```bash theme={null}
    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
    ```
  </Step>

  <Step title="Generate PQC Report (62443-4-2 FR 4 — long-lifecycle components)">
    ```bash theme={null}
    # 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
    ```
  </Step>

  <Step title="Export Findings Report (62443-4-1 Practice 5 / 62443-4-2 all FRs)">
    ```bash theme={null}
    # Full findings report for audit package
    curl -H "Authorization: Bearer ${TOKEN}" \
      "${BINARLY_API_URL}/api/v4/products/${PRODUCT_ID}/images/${IMAGE_ID}?contentType=pdf&imageFields=findings" \
      -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}?imageFields=findings" \
      -o findings.json
    ```
  </Step>
</Steps>

For a single-command script that downloads all artifacts, see [Compliance Artifacts — Automation Script](/api-reference/use-cases/compliance-artifacts#automation-script).

***

## Known Limitations

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

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

| 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                                |

***

## Related Documentation

<Columns cols={2}>
  <Card title="SBOM Export" icon="file-code" href="/user-guides/export/sbom">
    Generate binary-derived Software Bills of Materials in CycloneDX and SPDX formats.
  </Card>

  <Card title="CBOM Export" icon="key" href="/user-guides/export/cbom">
    Inventory all cryptographic algorithms, keys, and certificates in analyzed binaries.
  </Card>

  <Card title="VEX Export" icon="triangle-exclamation" href="/user-guides/export/vex">
    Communicate vulnerability exploitability status to downstream integrators and asset owners.
  </Card>

  <Card title="PQC Compliance Report" icon="atom" href="/user-guides/export/pqc">
    Assess post-quantum cryptography readiness for long-lifecycle IACS components.
  </Card>

  <Card title="Reachability Analysis" icon="diagram-project" href="/resource-center/reachability">
    Understand exploitability context for vulnerability prioritization.
  </Card>

  <Card title="Finding Classes" icon="list" href="/resource-center/finding-classes">
    Complete reference of all 238 finding classes and their security significance.
  </Card>
</Columns>