IEC 62443-4-1
secure product development lifecycle for OT and ICS suppliers
IEC 62443-4-1 (Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements) is the international standard that defines how a product supplier develops, ships, and maintains industrial automation and control system components securely. It names eight practices (Security Management, Specification of Security Requirements, Secure by Design, Secure Implementation, Security Verification and Validation Testing, Management of Security-Related Issues, Security Update Management, Security Guidelines), four maturity levels (initial, managed, defined, improving), the per-practice activities, and the per-product evidence the supplier needs to demonstrate the SDL was applied to a given product. This page covers the practices, the maturity model, the certification surface (ISASecure SDLA and equivalent assessor schemes), the relationship with IEC 62443-4-2, the wider IEC 62443 family, NIST SSDF, OWASP SAMM, BSIMM, the EU Cyber Resilience Act, and the audit-grade evidence pack a 62443-4-1 programme runs on.
No credit card required. Free plan available forever.
IEC 62443-4-1 explained for OT product suppliers, AppSec teams, and product security teams
IEC 62443-4-1 (Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements) is the international standard that defines how a product supplier develops, ships, and maintains an industrial automation and control system component securely. It is the process-side anchor in the wider IEC 62443 family, paired with the technical-side component requirements of IEC 62443-4-2. The standard names eight practices (Security Management, Specification of Security Requirements, Secure by Design, Secure Implementation, Security Verification and Validation Testing, Management of Security-Related Issues, Security Update Management, Security Guidelines), four maturity levels (initial, managed, defined, improving), the per-practice activities a supplier executes, and the per-product evidence pack the SDL produces.
For OT product manufacturers, embedded device makers, ICS suppliers, medical device makers, industrial automation vendors, IIoT platform suppliers, and transportation control unit manufacturers shipping into asset owners that operate under 62443, the standard is the SDL reference customer security reviews, regulatory disclosure obligations, certification bodies (ISASecure SDLA, 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 running the SDL discipline alongside broader application security programmes, the standard is the OT-specific reference that pairs with NIST SSDF, OWASP SAMM, and BSIMM on the IT side.
This page walks through the scope of the standard, the eight SDL practices and their activities, the four maturity levels, the per-product evidence pack the SDL produces, the failure modes the standard surfaces, the relationship with adjacent regimes (62443-4-2, the wider 62443 family, NIST SSDF, OWASP SAMM, BSIMM, the EU Cyber Resilience Act, ISO/SAE 21434), and where IEC 62443-4-1 sits alongside the SDLC vulnerability handoff workflow, the PSIRT product security incident response workflow, and the security feature launch readiness evidence pack workflow. Suppliers that adopt 62443-4-1 as the SDL anchor produce an evidence pack that holds up across the ISASecure SDLA assessment, customer-side security reviews, regulatory disclosure obligations, and internal audit on one operating record.
What IEC 62443-4-1 covers
The standard is the international anchor for secure development of industrial automation and control system components. It is broader than any single internal SDL policy and narrower than the wider 62443 family; the boundary is the product supplier role and the eight practices that span from organisational governance through end-of-life security guidance. Read sequentially across the document, the standard answers how a supplier operates a defensible SDL across a product family rather than how a single launch passes a security review.
Process requirements, not product requirements
IEC 62443-4-1 is the process side of the 62443-4 series. It defines the secure development lifecycle a product supplier follows when developing, shipping, and maintaining an industrial automation and control system component. The companion standard IEC 62443-4-2 is the technical side: the component requirements (CRs) the product itself must meet at each Security Level. Programmes typically pair the two: 62443-4-1 covers how the product is built; 62443-4-2 covers what the product does. ISASecure SDLA certifies the process side under 62443-4-1; ISASecure CSA or EDSA certifies the product side under 62443-4-2.
Anchored on eight practices and four maturity levels
The standard names eight practices (Security Management, Specification of Security Requirements, Secure by Design, Secure Implementation, Security Verification and Validation Testing, Management of Security-Related Issues, Security Update Management, Security Guidelines) and four maturity levels (initial, managed, defined, improving). The supplier programme is assessed per practice against per-level activity criteria. A 62443-4-1 evidence pack walks each practice from its activities to the per-product evidence the SDL was applied.
Product-supplier scope, OT and ICS audience
The standard targets the product supplier role: OEMs producing PLCs, RTUs, IEDs, gateways, HMIs, embedded software, industrial network devices, control system applications, and the firmware that ships with them. Adjacent product categories (medical devices, IIoT gateways, building automation controllers, transportation control units) increasingly read against 62443-4-1 as the SDL anchor because the asset owners they ship to use 62443 as the operating language. The asset owner side (62443-2-1) and the integrator side (62443-2-4) operate adjacent disciplines that 4-1 hands off to.
The eight SDL practices
The eight practices are the structural core of the standard. Each practice carries named activities (numbered SM-1 through SM-13, SR-1 through SR-5, SD-1 through SD-4, SI-1 through SI-2, SVV-1 through SVV-5, DM-1 through DM-6, SUM-1 through SUM-5, SG-1 through SG-7) and per-product evidence the supplier produces. The practices are sequential at the product level (requirements before design before implementation before testing) but operate continuously at the organisational level (issue handling, update management, and guidelines refresh run between product releases).
- 1
Practice 1: Security Management (SM)
Establish the SDL applicability statement, the documented secure development process, named SDL roles, security expertise on the development team, the secure development environment (developer workstation hardening, source repository protection, build server integrity, dependency cache protection), the tooling integrity process (third-party tool verification, in-house tool review, build reproducibility), and the security training programme. SM-1 through SM-13 are the governance baseline every later practice reads against.
- 2
Practice 2: Specification of Security Requirements (SR)
Document the product security context (the deployment environment the product is sold into), the threat model the design will resist, the per-product security requirements specification (conformance to relevant 62443-4-2 component requirements at the target Security Level), and the customer-side security responsibilities the product depends on. SR-1 through SR-5 produce the requirements artefact every later design, implementation, and verification step builds against.
- 3
Practice 3: Secure by Design (SD)
Apply the secure-by-design principles to the architecture: defense-in-depth design, secure design best practices (least privilege, separation of duties, fail-secure defaults, simplest defensible interface), the threat model that gets refreshed when the design changes, the design review with documented outcomes and named reviewer, the secure component selection (third-party component evaluation against the SDL the product supplier expects of itself). SD-1 through SD-4 produce the design artefacts the implementation step builds against.
- 4
Practice 4: Secure Implementation (SI)
Implement the design using documented secure coding standards (CERT C, CERT C++, MISRA C, language-specific guidelines per runtime), a code review process (peer review and automated tooling), and the implementation traceability back to the design and the requirements. SI-1 and SI-2 produce the source code artefacts and the review evidence the verification step reads against. The standard does not mandate a specific tool but expects the supplier to demonstrate the secure coding standard is applied and the review evidence exists.
- 5
Practice 5: Security Verification and Validation Testing (SVV)
Test the implementation against the security requirements. SVV activities cover security requirements testing (does the product meet each SR), threat mitigation testing (do the design mitigations work in practice), vulnerability testing (static application security testing, software composition analysis, dynamic analysis, fuzz testing), penetration testing (manual offensive testing per defined test plan), and the test plan and test report record. SVV-1 through SVV-5 produce the verification evidence the certification assessor and the customer-side security review both read.
- 6
Practice 6: Management of Security-Related Issues (DM)
Receive, triage, investigate, and disclose security-related issues across the product family. DM activities cover the receipt of security-related issue reports (internal teams, customers, researchers, ISACs, regulators), the investigation discipline, the assessment of impact across product versions and variants, the periodic security review of the issue backlog, and the disclosure to affected parties. DM-1 through DM-6 produce the vulnerability handling record the customer-side asset owner reads against and the regulatory disclosure obligation (under the EU Cyber Resilience Act, sector regulations, and contractual obligations) feeds.
- 7
Practice 7: Security Update Management (SUM)
Develop, qualify, and distribute security updates to deployed products. SUM activities cover the security update qualification (does the update fix the issue without breaking the control system function), the timely delivery against documented response targets per severity band, the documentation of dependencies on third-party component updates, and the secure delivery (signed updates, verified delivery channel, integrity verification at the receiving asset). SUM-1 through SUM-5 produce the patch release record the customer-side patch management process (paired with IEC 62443-2-3) reads against.
- 8
Practice 8: Security Guidelines (SG)
Document the security guidance the product user (asset owner, system integrator, operator) needs to deploy, operate, and maintain the product securely. SG activities cover the product defense-in-depth documentation, the security hardening guidelines, the secure configuration documentation, the operational security guidelines, the account management guidelines, the secure decommissioning guidance, and the end-of-life security communication. SG-1 through SG-7 produce the product security documentation the integrator and asset owner read against when applying 62443-2-4 integration controls and 62443-2-1 operating controls.
The four maturity levels
The standard names four maturity levels per practice. A supplier programme typically sits at different levels across the eight practices: a well-managed security update process running at Maturity Level 3 alongside an initial-stage threat modelling practice at Maturity Level 1. The ISASecure SDLA assessment reads against the per-practice maturity claim, and certification levels (SDLA Maturity Level 2, 3, or 4) reflect the lowest maturity across the practices included in the assessment scope.
| Level | What it looks like in practice |
|---|---|
| Maturity Level 1: Initial | Practices are performed but not documented as a repeatable process. Activities happen on individual products through informal expertise rather than through a defined organisational discipline. Output quality depends on which engineers participate. Most starting suppliers sit here for one or two practices and progress unevenly across the eight. |
| Maturity Level 2: Managed | Practices are documented, repeated across products, and managed against named owners and timelines. Each practice has a process description, a named owner, and a record of execution per product. Output quality is more consistent across the product family. Most suppliers seeking ISASecure SDLA Maturity Level 2 certification need to demonstrate the documented process exists and has been applied to the products in scope. |
| Maturity Level 3: Defined | Practices are tailored from an organisational standard, with documented adaptations per product family. The organisation has a defined SDL that products inherit from and adapt to. Improvements are propagated organisation-wide rather than left on individual product programmes. Certification at Maturity Level 3 expects evidence the organisational standard is genuinely the source of the per-product process. |
| Maturity Level 4: Improving | Practices are continuously improved against measured outcomes. The organisation maintains process metrics per practice, identifies process weaknesses against the metrics, and propagates improvements across the product family. Maturity Level 4 is the highest level the standard defines; few suppliers operate at this level across all eight practices, and the certification path is typically progressive across multiple assessment cycles. |
The per-product evidence pack the SDL produces
The standard expects a defined artefact set per product rather than a single document. The pack below is the minimum durable set most supplier programmes maintain when they adopt IEC 62443-4-1 as the SDL anchor. 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.
- An SDL applicability statement that names the products in scope, the practice set applied per product, the maturity level claimed per practice, the SDL owner, and the review cadence. The applicability statement is the artefact the ISASecure SDLA assessor reads first when scoping the assessment and the customer reads when verifying the supplier claim on the product purchase record.
- A per-product security requirements specification that walks the product security context, the threat model, the conformance to relevant 62443-4-2 component requirements at the target Security Level, the customer-side security responsibilities the product depends on, and the traceability from each requirement to the design and verification artefact. The specification is the artefact the SR practice produces and the SD, SI, SVV, and SG practices all read against.
- A per-product threat model that walks the assets in scope, the trust boundaries on the architecture, the threat actors the product is expected to resist, the threats enumerated against each asset, the mitigations credited per threat, and the residual risks accepted with documented rationale. The threat model is refreshed when the design changes, when the threat landscape shifts materially, and when a security-related issue surfaces a threat the original model missed.
- A secure design review record per product that walks the design decisions credited under the secure-by-design principles, the named reviewer, the review date, the issues raised, the dispositions, and the design changes made. The review record is the artefact the SD practice produces and the SI and SVV practices build against.
- A code review and SAST/SCA evidence record per product that walks the secure coding standard applied, the static analysis tool output (findings, suppressions with rationale, fixed items), the software composition analysis output (dependencies with known vulnerabilities, supplier remediation status, customer-side mitigations), the peer review evidence, and the closure trail for findings. The record is the artefact the SI practice produces and the SVV practice reads against.
- A security verification and validation test plan and test report per product that walks the requirements testing matrix, the threat mitigation testing outcomes, the vulnerability testing results, the penetration testing scope and findings, the test environment integrity evidence, and the per-finding closure trail. The plan and the report together are the artefact the SVV practice produces and the certification assessor reads end-to-end.
- A security-issue handling record per product family that walks every received report (internal, customer, researcher, ISAC, regulator), the triage outcome, the investigation evidence, the impact assessment across versions and variants, the affected SKU list, the customer notification record, and the public disclosure record where applicable. The issue handling record is the artefact the DM practice produces and the regulatory disclosure obligation and customer-side asset owner both read.
- A security update release record per product that walks the qualification evidence (does the update fix the issue without breaking the product), the delivery target met against the documented response targets per severity band, the dependency on third-party component updates, the secure delivery evidence (update signing certificate, secure distribution channel, integrity verification at receive), the customer notification, and the post-delivery feedback. The release record is the artefact the SUM practice produces and the customer-side patch management process reads against.
- A customer-facing security documentation pack per product that walks the defense-in-depth narrative, the hardening guidelines, the secure configuration documentation, the operational security guidelines, the account management guidelines, the secure decommissioning guidance, and the end-of-life security communication. The pack is the artefact the SG practice produces and the integrator and asset owner read when applying 62443-2-4 and 62443-2-1 controls.
Failure modes the standard surfaces
The standard is forgiving on the choice of tooling, the wording of the secure coding standard, and the structure of the per-product evidence pack. It is unforgiving about a small number of patterns that turn the SDL programme cosmetic rather than operational. The patterns below recur across supplier programmes and are the ones that erode certification credibility, customer-side security review confidence, and regulatory disclosure defensibility most reliably.
- Treating the SDL as a one-product exercise. Suppliers that apply the eight practices to the flagship product and never propagate to the wider product family produce a defensible claim for one SKU and a credibility gap for everything else. The standard expects the SDL to be an organisational discipline, with the applicability statement naming the in-scope product set and the per-practice activities reaching every product in scope.
- No documented secure coding standard. Suppliers that perform code review without naming the secure coding standard the review reads against produce evidence the SI practice runs but no anchor for how strict the review is. Assessors and customer-side security reviews both read for a named standard (CERT C, CERT C++, MISRA C, language-specific guidelines), the adoption evidence, and the review checklists tied to the standard.
- SVV tests as a launch-week exercise. Suppliers that run security testing against a single milestone and never run regression testing against subsequent firmware releases produce SVV evidence that decays the moment the next release ships. The standard expects the test plan to walk the per-release expectations and the test report to be regenerated against the as-shipped firmware build.
- Defect handling that fails to enumerate affected versions. Suppliers that handle security-related issues against the current firmware release and never trace impact across legacy versions and SKU variants produce a vulnerability handling record that closes the issue on paper while leaving deployed installations exposed. The DM practice expects per-issue impact enumeration across versions, variants, and shipped SKUs, with the customer notification record reflecting the full impact set.
- Security update qualification that misses control system function regression. Suppliers that test security updates for the security fix but not for the operational impact on the control system function produce a patch the customer-side asset owner cannot deploy because it breaks the historian, the HMI, the proprietary protocol, or the licensed feature. The SUM practice expects the qualification evidence to walk both the security fix and the operational regression test.
- No customer-facing security documentation refresh. Suppliers that publish security guidelines at first release and never refresh them as the product evolves leave the integrator and the asset owner working from documentation that describes a product version no longer deployed. The SG practice expects the documentation pack to be refreshed against the as-shipped firmware build and the security guidelines to reflect the current secure configuration and hardening recommendations.
- SDL evidence reconstructed at certification time. Suppliers that maintain the SDL artefacts informally and reconstruct the evidence pack at the certification assessment cycle produce a defensible claim for the certification window and a credibility gap between cycles. The standard expects the SDL to operate as a continuous discipline, with the artefacts produced as a residue of the operating record rather than rebuilt against the assessment cycle.
- Confusion between 62443-4-1 evidence and 62443-4-2 evidence. Suppliers that conflate the process-side certification (SDLA, 62443-4-1) with the product-side certification (CSA, EDSA, 62443-4-2) produce a single evidence pack that satisfies neither. The two are paired but distinct: 62443-4-1 evidences how the product is built; 62443-4-2 evidences what the product does. Programmes that operate the two as separate disciplines produce defensible evidence packs for both.
How IEC 62443-4-1 relates to adjacent regimes
IEC 62443-4-1 sits inside a busy OT and product-security regulatory and assurance neighbourhood. The relationships below are the ones programmes encounter most often when they read 4-1 against the rest of the operating regime. Suppliers shipping across regions and sectors use 62443-4-1 as the SDL anchor and read 62443-4-2, the wider 62443 family, NIST SSDF, OWASP SAMM, BSIMM, the EU Cyber Resilience Act, ISO/SAE 21434, and sector device-cybersecurity guidance as the contextual layers around it.
IEC 62443-4-1 vs IEC 62443-4-2
IEC 62443-4-1 is the process side: how the product supplier develops, ships, and maintains a component securely (the eight SDL practices). IEC 62443-4-2 is the technical side: the component requirements (CRs) the component itself must meet at each Security Level (organised under the seven foundational requirements). Programmes pair them: 4-1 evidences the SDL was applied, 4-2 evidences the component meets the requirements. ISASecure SDLA certifies 4-1; ISASecure CSA or EDSA certifies 4-2. Suppliers seeking both produce two distinct evidence packs that read against each other on the same product record.
IEC 62443-4-1 vs the wider 62443 family
The wider IEC 62443 family covers the operating environment around the product. IEC 62443-2-1 is the asset owner cybersecurity management system. IEC 62443-2-3 is patch management between asset owners and product suppliers (the customer-side counterpart to the supplier SUM practice). IEC 62443-2-4 is the system integrator security programme. IEC 62443-3-2 is the security risk assessment for system design. IEC 62443-3-3 is the system-level security requirements. The 4-1 SDL produces the components the rest of the family operates around. Suppliers reading the broader family understand which evidence customers will request when integrating the component into the wider control system.
IEC 62443-4-1 vs NIST SSDF (SP 800-218)
The NIST Secure Software Development Framework (SP 800-218) is the US federal anchor for secure software development across IT software. IEC 62443-4-1 is the international anchor for secure development of industrial automation and control system components. The two share heritage and many practices overlap (secure design, secure coding, vulnerability handling, security update management). Suppliers shipping to both US federal customers and OT asset owners often map their SDL to both anchors and produce one evidence pack that reads against both. The 4-1 specifics around control system function regression testing, customer-side security responsibilities, and integration documentation are not as deeply elaborated in SSDF and remain 4-1-specific.
IEC 62443-4-1 vs OWASP SAMM and BSIMM
OWASP SAMM and BSIMM are software security maturity models broadly applicable to IT software development. IEC 62443-4-1 is the OT-specific anchor with the maturity model built directly into the standard (four maturity levels per practice). The three are compatible: suppliers running SAMM or BSIMM as the IT-side maturity model often read 62443-4-1 alongside as the OT-specific reference, with the additional 62443-4-1 expectations around hardware product lifecycle, firmware release discipline, and customer-side documentation pack layered on top of the broader maturity model.
IEC 62443-4-1 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-1 is one of the standards manufacturers can read against for the vulnerability handling and secure development requirements. Suppliers preparing for CRA compliance often build the SDL programme on 62443-4-1 and surface the same evidence pack against the CRA conformity assessment route, the ISASecure SDLA assessment, and customer-side security reviews simultaneously.
IEC 62443-4-1 vs ISO/SAE 21434 (automotive)
ISO/SAE 21434 (Road vehicles, Cybersecurity engineering) is the automotive cybersecurity engineering standard. The two share structural heritage (concept phase, product development, post-development, governance, management of cybersecurity activities) but target different industries and different regulatory environments. Suppliers that ship into both industrial and automotive markets often build one SDL programme that reads against both standards, with the per-standard evidence pack derived from the same operating record. The 62443-4-1 vocabulary around Security Levels, foundational requirements, and asset owner / integrator / supplier roles maps onto the 21434 vocabulary around cybersecurity goals, claims, and item definitions.
Where SecPortal fits in an IEC 62443-4-1 programme
SecPortal is the operating layer for the SDL evidence lifecycle, not a replacement for the product security programme strategy, the engineering accountability for the design and implementation, the certification body relationship, or the regulator dialogue the standard expects. The platform handles the SDL-side workstreams (per-practice evidence capture, per-product requirements and threat model record, code-scan and SAST and SCA evidence, SVV test plan and report, security-issue handling backlog, security update release record, customer-facing documentation versioning, certification assessment readiness pack) 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 SDL record hosts the security finding evidence, the credential lifecycle for the developer and build infrastructure, and the continuous monitoring of any IT-side supplier portals that touch the product update channel.
- Engagement management dedicated to the SDL programme, with one engagement record per product (or per product family where appropriate) so the SDL applicability statement, the per-practice activity evidence, the per-product security requirements specification, the threat model, the design review record, the code review and SAST/SCA evidence, the SVV test plan and report, the security-issue handling backlog, the security update release record, and the customer-facing security documentation pack sit on one record rather than being stitched together across email threads, document drives, and ticketing systems at certification time.
- Code scanning (SAST and SCA via GitHub, GitLab, and Bitbucket OAuth) that runs against the product source repository so the SI practice (secure implementation) and the SVV practice (vulnerability testing) produce verifiable evidence inside the same workspace the rest of the SDL record lives on. SAST findings tie to the affected file and CWE; SCA findings tie to the affected dependency, version, and known CVE. Per-finding state, severity, override decision, and closure trail are all structured records.
- Findings management with structured records, CVSS 3.1 scoring, CWE tagging, and per-finding asset binding so the security-issue handling record under the DM practice, the SVV vulnerability test outcomes, and the security update release record under the SUM practice all read against the same operating record. Per-version impact, per-SKU affected list, and per-customer notification reference all sit on the structured finding record rather than on a parallel spreadsheet.
- Document management with versioning for the SDL applicability statement, the per-product security requirements specification, the threat model, the design review record, the SVV test plan and report, the security-issue handling guidance, the customer-facing security guidelines pack, and the legal correspondence on regulatory disclosure obligations. Version history per artefact lets the certification assessor, the customer-side security review, and the regulator reconstruct the artefact set at any point in the product lifecycle.
- AI report generation that turns the structured SDL record into the leadership-read SDL programme summary, the certification assessment readiness pack, the customer security review response, the regulatory disclosure draft (CRA Article 11 reporting obligations, sector regulator obligations), and the per-product security claim attestation, working against the structured operating record rather than against unstructured email content.
- Activity log with CSV export that captures every state change on the SDL record (practice activity executed, requirement added, threat model refreshed, design review closed, code review completed, SAST or SCA finding raised, SVV test executed, security-related issue received, security update released, customer notification dispatched, customer-facing documentation updated). The activity log is the audit trail the certification assessor, the regulator, and counsel can reconstruct the SDL timeline from without a multi-team excavation.
- Retesting workflows that walk the per-issue closure verification, the regression testing across firmware releases, and the SVV repeat-testing discipline so the verification evidence does not decay between releases. The retest record carries the per-test outcome, the per-finding closure trail, and the activity log entry that ties the regression evidence to the SDL operating record.
- Role-based access control (owner, admin, member, viewer, billing) that keeps the SDL programme owner, the security engineering team, the product engineering team, the AppSec team, the GRC team, the customer-facing technical writers, and external assessors on one workspace with appropriate per-role scoping. MFA enforcement on accounts that touch the SDL record so the audit trail is identity-grounded for certification assessment and regulatory inquiry.
- Compliance tracking that reads the same evidence pack across IEC 62443-4-1, IEC 62443-4-2 (the component requirements companion), the wider 62443 family (asset-owner, integrator, system requirements), NIST SSDF (SP 800-218), OWASP SAMM, BSIMM, the EU Cyber Resilience Act conformity assessment, ISO/SAE 21434 for automotive cross-shippers, and sector-specific regimes (medical device cybersecurity guidance, transportation control unit guidance), so the cross-regime read is reconcilable rather than reconciled per certification cycle.
- 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 SVV finding deferrals, the SAST and SCA false-positive dispositions, and the customer-side accepted-residual-risk records carry the same audit-grade decision shape as the broader security exception register. Named approvers, dated decisions, and renewal cadences read against the SDL operating record at the next certification assessment.
- Continuous monitoring schedules (daily, weekly, biweekly, monthly) so the SDL programme stays current between certification cycles: re-running SCA against the dependency graph, re-running SAST against the current source, re-running external posture checks against any IT-side supplier portals, with the verification evidence attached to the SDL 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 products, does not act as a notified body, does not issue ISASecure SDLA certifications or 62443-4-1 conformity statements, does not replace the supplier accountability for the SDL discipline, does not ship runtime detection for control system components, does not auto-deploy security updates to deployed assets, 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 SDL practice gates, and does not maintain product certification customer logos, adoption metrics, ROI numbers, compliance guarantees, or any claim of pre-approved ISASecure SDLA or 62443-4-1 conformity. The verified capability stack covers the evidence-record discipline the standard expects across the eight practices; the certification path remains an exercise between the supplier, the assessor (ISASecure, TUV, and equivalent), and the regulator.
The SDL evidence (per-practice activity record, per-product requirements specification, threat model, design review, code review, SAST and SCA evidence, SVV test plan and report, security-issue handling backlog, security update release record, customer-facing documentation pack) reads against operational workflows that already exist as named use cases. The SDLC vulnerability handoff workflow carries the per-finding handoff discipline the SI, SVV, and DM practices produce. The PSIRT workflow carries the security-issue handling backlog the DM practice operates against. The SBOM and VEX publishing workflow carries the per-product component transparency the SR, SUM, and SG practices reference. The audit fieldwork evidence request workflow carries the certification assessment fieldwork-day evidence packaging the SDL record feeds.
For product security teams operating the SDL alongside the wider application security programme, the product security teams workspace covers the SDL 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 SDL operating record reads against. For internal security teams at OT product supplier organisations carrying the programme- level accountability for the SDL discipline and the regulatory disclosure obligation, the internal security teams workspace covers the platform-level reporting and the cross-team handoff the SDL 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-1 reads against. For CISOs and security leaders accountable for the SDL programme posture and the named-decision accountability for product security claims, the CISOs and security leaders workspace covers the executive-layer reporting model that sits on top of the SDL operating 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-1 sits inside. The NIST SSDF framework page covers the US federal anchor for secure software development that pairs with 62443-4-1 on cross-shippers. The OWASP SAMM framework page and the BSIMM framework page cover the broader application security maturity models the IT-side programmes typically read against, and which suppliers running both IT and OT product lines pair with 4-1. The EU Cyber Resilience Act framework page covers the EU regulation that increasingly references 62443-4-1 as a conformity assessment anchor for products with digital elements. The CISA Secure by Design framework page covers the US federal secure-by-design principles that operate alongside the standard for suppliers shipping into US federal customers. The container image signing operating model guide covers the secure software delivery discipline that the SUM practice references for signed-update delivery. The software bill of materials guide covers the SBOM discipline that the SR and SUM practices reference for component transparency and security update qualification.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Practice 1: Security Management (SM)
Establish the governance baseline for the secure development organisation: a documented SDL applicable to in-scope products, named roles and responsibilities, security expertise on the development team, a documented process for security training, a process for the secure development environment (developer workstation hardening, source repository protection, build server integrity), and a process for ensuring third-party tooling integrity. Activities SM-1 through SM-13 are the foundation every other practice reads against.
Practice 2: Specification of Security Requirements (SR)
Document the product security context, the threat model, and the per-product security requirements set. Requirements address the intended product security context (the deployment environment and the threat actors the product is expected to resist), the conformance to relevant 62443-4-2 component requirements (per Security Level), and the customer-side security responsibilities the product depends on. SR-1 through SR-5 produce the security requirements specification the design, implementation, and verification steps read against.
Practice 3: Secure by Design (SD)
Apply secure-by-design principles to the product architecture. Activities cover the defense-in-depth design, the secure design best practices, the threat model that gets updated when the design changes, the design review with documented outcomes, and the secure component selection (third-party component evaluation against the SDL the product supplier expects of itself). SD-1 through SD-4 produce the design artefacts the implementation step builds against.
Practice 4: Secure Implementation (SI)
Implement the design using secure coding practices, named secure coding standards (often CERT, MISRA, language-specific guidelines depending on the runtime), and a code review process. Activities cover the secure coding standards adoption, the code review (peer review or automated), and the implementation of the secure design. SI-1 and SI-2 produce the source code artefacts and the review evidence the verification step reads against.
Practice 5: Security Verification and Validation Testing (SVV)
Test the implementation against the security requirements. Activities cover security requirements testing (does the product meet each SR), threat mitigation testing (do the design mitigations work in practice), vulnerability testing (static analysis, dynamic analysis, software composition analysis, fuzz testing), penetration testing (manual offensive testing per defined plan), and the test plan and test report record. SVV-1 through SVV-5 produce the verification evidence the certification assessor and the customer-side security review both read.
Practice 6: Management of Security-Related Issues (DM)
Receive, triage, investigate, and disclose security-related issues across the product family. Activities cover the receipt of security-related issue reports (internal teams, customers, researchers, ISACs, regulators), the issue investigation discipline, the assessment of impact across product versions and variants, the periodic security review of the issue backlog, and the disclosure to affected parties. DM-1 through DM-6 produce the vulnerability handling record the customer-side asset owner reads against and the regulatory disclosure obligation feeds.
Practice 7: Security Update Management (SUM)
Develop, qualify, and distribute security updates. Activities cover the security update qualification (does the update fix the issue without breaking the product), the timely delivery of security updates against documented response targets, the documentation of dependencies on third-party component updates, and the secure delivery (signed updates, verified delivery channel). SUM-1 through SUM-5 produce the patch release record the customer-side patch management process (paired with IEC 62443-2-3) reads against.
Practice 8: Security Guidelines (SG)
Document the security guidance the product user (asset owner, system integrator, operator) needs to deploy, operate, and maintain the product securely. Activities cover the product defense-in-depth documentation, the security hardening guidelines, the secure configuration documentation, the operational security guidelines, and the account management guidelines. SG-1 through SG-7 produce the product security documentation the integrator and asset owner read against when applying 62443-2-4 integration controls and 62443-2-1 operating controls.
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-1-aligned SDL programme on one record
Hold the SDL applicability statement, the per-product security requirements specification, the threat model, the secure design review record, the code-review and SAST/SCA evidence, the SVV test plan and test report, the security-issue handling backlog, the security update release record, and the customer-facing security guidelines on one workspace, then read the same record across IEC 62443-4-1, IEC 62443-4-2, the wider 62443 family, NIST SSDF, OWASP SAMM, and the EU Cyber Resilience Act. Start free.
No credit card required. Free plan available forever.