Secure Development Frameworks Compared: SSDF, SAMM, BSIMM, 27034, 62443-4-1 and the CRA

Software teams are asked to "follow a secure development framework" by customers, auditors and now regulators, but the frameworks on offer do very different jobs and are often confused. NIST SSDF is a set of outcome practices, OWASP SAMM is a prescriptive maturity model, BSIMM is a descriptive benchmark of what other firms do, ISO/IEC 27034 is a governance framework for application security controls, IEC 62443-4-1 is a certifiable product development lifecycle for industrial components, and Annex I of the EU Cyber Resilience Act (CRA) is a legal list of essential requirements. This guide compares the six on purpose, structure, evidence and assurance, shows where each falls short, and explains how to combine them so one engineering programme answers a customer questionnaire, a maturity review and a CRA conformity assessment. It is for AppSec leads, product security officers, engineering managers and compliance teams at software producers and manufacturers.

Key takeaways

• Different questions, different tools. SSDF says what outcomes a producer should achieve, SAMM how to grow toward them, BSIMM what peers actually do, 27034 how to govern controls per application, 62443-4-1 what an auditable product lifecycle looks like, and the CRA what the law requires a product to be.
• Only the CRA is binding in itself. Its reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027; the other five are voluntary unless a contract, customer or certification scheme calls them up.
• No framework alone proves CRA conformity. SSDF, SAMM and 62443-4-1 cover much of the process side of Annex I Part II, but the product properties in Part I and the technical documentation still need product-level evidence.
• Measure with one, build with another. A common pattern is SAMM or BSIMM to measure the programme, SSDF as the shared vocabulary with customers, and 62443-4-1 or the CRA as the product-level target where they apply.
• Build pipelines and their identities are in scope everywhere. Every framework expects protected development environments and update integrity, which in practice means controlling CI/CD service accounts, tokens and signing keys.

The six frameworks at a glance

Each framework has its own deep guide; this page compares them. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide, the OWASP SAMM Guide, the BSIMM guide, the ISO/IEC 27034 guide, the IEC 62443-4-1 and 4-2 Secure Product Development Guide and the EU Cyber Resilience Act Guide.

NIST SSDF: the common vocabulary

What it is: NIST SP 800-218, Secure Software Development Framework Version 1.1, final since 3 February 2022, is a core set of high-level practices that can be added to any software development lifecycle. NIST says following them should reduce vulnerabilities in released software, limit the impact of flaws that are not found and address root causes, and gives purchasers and suppliers a common vocabulary. Practices sit in four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). SP 800-218 Rev. 1 (SSDF version 1.2) was released as an initial public draft on 17 December 2025; its comment period closed on 30 January 2026 and no final is listed, so cite v1.1.

Threat model: vulnerabilities in released software and compromise of the development process. It does not set a capability level; the producer decides how far to go.

Where it fails in practice: an SSDF claim backed only by policy, with no toolchain evidence; tasks mapped to tools that are installed but not enforced on every repository; and RV practices that exist on paper with no route for external vulnerability reports.

Best fit: answering customer and government questionnaires, and as the crosswalk hub between the other frameworks.

OWASP SAMM: the prescriptive roadmap

What it is: an open, vendor-neutral maturity model, currently version 2.0, with five business functions: Governance (Strategy and Metrics, Policy and Compliance, Education and Guidance), Design (Threat Assessment, Security Requirements, Secure Architecture), Implementation (Secure Build, Secure Deployment, Defect Management), Verification (Architecture Assessment, Requirements-driven Testing, Security Testing) and Operations (Incident Management, Environment Management, Operational Management). Each practice has two streams and three maturity levels, assessed with quality criteria.

Threat model: organisational immaturity. SAMM assumes risk comes from missing or uneven practices and helps set a risk-based target per practice.

Where it fails in practice: chasing level 3 everywhere, changing assessment scope between rounds so trends mean nothing, and generous self-scoring that the quality criteria would not support.

Best fit: building a multi-year roadmap and showing year-on-year progress, especially for small and mid-sized teams that cannot fund a benchmark.

BSIMM: the peer benchmark

What it is: Black Duck describes BSIMM as a descriptive model that documents what software security initiatives actually do. BSIMM16, published in January 2026, analyses 111 organisations and measures 128 activities across 12 practices in four domains: Governance, Intelligence, SSDL Touchpoints and Deployment. Assessors interview stakeholders, review documentation, validate claims and map activities to the model, producing a scorecard against peers.

Threat model: none of its own. It tells you where you stand against firms like you, not what you should do next.

Where it fails in practice: treating the peer average as a target in a sector where peers are weak, and using a scorecard to justify budget without turning it into a plan. Pair it with a prescriptive model.

Best fit: large software security initiatives that need external comparison for boards and investment cases.

ISO/IEC 27034: governing controls per application

What it is: ISO/IEC 27034-1:2011, Application security Part 1: Overview and concepts, last confirmed in 2022, gives definitions, concepts, principles and processes for building security into how applications are managed, whether developed in-house, acquired or outsourced. Its central idea is an Organisation Normative Framework holding the organisation's application security policies, processes, roles and controls, from which each application selects controls to reach a targeted level of trust.

Threat model: application-specific, from the risk assessment that sets each application's level of trust. The controls themselves come from your own sources, such as OWASP ASVS (see the OWASP ASVS Guide).

Where it fails in practice: heavy upfront design that never reaches developers, and a control library that is not linked to tests in the pipeline.

Best fit: organisations with an ISO/IEC 27001 ISMS that want application security governed in the same style, and those managing many acquired and outsourced applications.

IEC 62443-4-1: the certifiable product lifecycle

What it is: ISA lists ANSI/ISA-62443-4-1-2018, Secure product development lifecycle requirements, as the supplier part of the 62443 series. Its eight practices are security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management and security guidelines. The ISA Security Compliance Institute offers SDLA certification for supplier development processes.

Threat model: products deployed in industrial automation and control systems, specified through a product security context and threat model and linked to component security levels in 62443-4-2.

Where it fails in practice: certifying one product line's process and implying it covers acquired lines, and security guidelines (SG) for integrators that are left out of the shipped documentation.

Best fit: OT and industrial component suppliers, and any manufacturer whose customers require third-party certification of the development process.

EU CRA Annex I: the legal floor

What it is: Regulation (EU) 2024/2847 entered into force on 10 December 2024. Under Article 71, Chapter IV on conformity assessment bodies applies from 11 June 2026, Article 14 reporting obligations from 11 September 2026, and the Regulation generally from 11 December 2027. The Commission's CRA page, last updated 7 September 2026, shows the same dates. Annex I Part I requires products to be placed on the market without known exploitable vulnerabilities, with a secure-by-default configuration, support for security updates, protection against unauthorised access, confidentiality and integrity protection, data minimisation, availability protection, limited attack surface, exploitation mitigation, activity logging and secure data deletion. Part II requires manufacturers to document components including a software bill of materials covering at least top-level dependencies, remediate without delay, test regularly, disclose fixed vulnerabilities, operate a coordinated vulnerability disclosure policy, provide a reporting contact, distribute updates securely and disseminate security updates without delay.

Threat model: product risk, from the cybersecurity risk assessment required under Article 13, applied to every product with digital elements in scope.

Where it fails in practice: assuming an existing SDLC framework certificate equals conformity, producing an SBOM once at release rather than maintaining it, and missing the split between security and functionality updates that Part II asks for where technically feasible.

Best fit: mandatory for manufacturers placing in-scope products on the EU market. See the EU Cyber Resilience Act Readiness Checklist for Manufacturers.

Crosswalk: how the frameworks cover the same work

Use this crosswalk as a starting point and confirm task-level mappings against each framework's own text before using them as audit evidence.

Where identity fits

Every framework expects the development environment and release process to be protected, and the weak point is usually machine identity: CI/CD service accounts, repository deploy keys, package publishing tokens and code signing keys. SSDF PS practices, SAMM Secure Build and Secure Deployment, 62443-4-1 SM requirements on protecting private keys and the CRA's integrity and secure update requirements all land on these credentials. In the SolarWinds supply chain compromise, attackers with access to the build environment injected a backdoor during the build without changing the source repository, and the tampered builds went through normal signing, so customers trusted them. Short-lived, scoped pipeline credentials, signing keys held in hardware and build verification against source are controls every framework above can claim. See the SLSA and Build Provenance Guide and the Software Supply Chain Security Guide.

Decision guidance: which to lead with

• Selling software to US government or regulated enterprises: lead with SSDF as the language of questionnaires and attestations; use SAMM to plan improvements.
• Manufacturer of products for the EU market: the CRA is mandatory. Build an Annex I requirement register, then use SSDF or 62443-4-1 as the process to produce the evidence. Watch for harmonised standards, which will define presumption of conformity.
• Industrial or OT component supplier: 62443-4-1 with SDLA certification is what asset owners ask for, and it covers a large share of CRA Part II process work.
• Large enterprise with a mature programme: BSIMM for external benchmarking, SAMM or an internal roadmap for planning.
• Small team starting out: SAMM with a modest target profile plus the SSDF task list; skip paid benchmarks until the basics are in place.
• Organisation with an ISO/IEC 27001 ISMS and many acquired applications: 27034 to govern controls per application, with ASVS as the control source.

Worked scenario: one producer, four demands

A company sells a network management product to EU customers and an OT gateway to utilities, and receives US enterprise questionnaires that reference SSDF. Its board wants a maturity measure.

1. Baseline: it runs a SAMM assessment across both product lines with fixed scope, and records target levels per practice.
2. Process spine: it writes one secure development procedure structured on the 62443-4-1 practices, because the OT gateway needs SDLA certification, and tags each step with its SSDF task.
3. Legal register: for each product it maps the 13 Part I points and 8 Part II points to procedure steps and product evidence: SBOM per release, CVD policy, update channel signing, secure defaults.
4. Pipeline controls: it moves build credentials to short-lived workload identity, puts signing keys in an HSM and generates provenance for each release, which serves SSDF PS, SAMM Secure Build, 62443-4-1 SM and CRA integrity.
5. Reporting: it sets up the vulnerability intake and reporting workflow needed for CRA Article 14 obligations from 11 September 2026, reusing the 62443-4-1 DM process. See the PSIRT Guide.

Implementing a combined programme

1. Confirm obligations: which products fall under the CRA, which customers require SSDF attestation or 62443 certification, and the version of each framework you will cite.
2. Measure first: run a SAMM or BSIMM baseline so you know the starting point.
3. Choose the process spine: SSDF for general software, 62443-4-1 where certification is needed.
4. Build the crosswalk: map the spine to every other framework you must answer to, at task level.
5. Automate evidence: configure pipelines to produce scan results, SBOMs, provenance and review records as by-products.
6. Pilot on one product: run a mock conformity assessment or certification readiness review and fix gaps before scaling.
7. Roll out and reassess: extend to other products, reassess maturity annually with unchanged scope, and update the crosswalk when SSDF v1.2 is finalised or harmonised standards are published.

Detection and measurement

• Crosswalk coverage: percentage of CRA Annex I points and SSDF tasks with named, automated evidence.
• Pipeline enforcement: percentage of repositories where required security checks block merges, not just run.
• SBOM currency: percentage of releases shipped with a current machine-readable SBOM.
• Vulnerability response time: median days from report to fix for critical issues, by product.
• Pipeline credential hygiene: count of long-lived tokens and keys in CI/CD, trending to zero.
• Maturity trend: SAMM score against target per practice, same scope each year.

Framework mapping

Common failure patterns

• Confusing a maturity score with compliance: a good SAMM or BSIMM result says nothing about whether a specific product meets CRA Annex I.
• Policy without pipeline evidence: SSDF or 27034 documents that no build ever enforces.
• Running each framework separately: duplicate questionnaires and assessments that disagree with each other.
• Ignoring build identities: long-lived CI tokens and signing keys on build servers, the path seen in SolarWinds.
• Citing drafts as final: quoting SSDF v1.2 draft tasks or unpublished harmonised standards as settled requirements.

Practitioner checklist

• List which frameworks are binding or contractually required for each product, with version and status date.
• Baseline maturity with SAMM or BSIMM using a fixed, documented scope.
• Pick one process spine and tag each step with SSDF tasks.
• Keep a CRA Annex I register per in-scope product with evidence links.
• Generate SBOMs, scan results and provenance automatically for every release.
• Replace long-lived pipeline credentials with short-lived identity and protect signing keys in hardware.
• Run a coordinated vulnerability disclosure policy and a reporting workflow ready for CRA Article 14.
• Reassess annually and update the crosswalk when SSDF v1.2 or CRA harmonised standards are finalised.

Standards and references

• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
• NIST: SP 800-218, Secure Software Development Framework Version 1.1
• NIST: SP 800-218 Rev. 1 (SSDF Version 1.2) Initial Public Draft
• ISA: ISA/IEC 62443 Series of Standards
• ISO: ISO/IEC 27034-1 Application security, Overview and concepts
• OWASP: SAMM Model
• Black Duck: BSIMM report
• European Commission: Cyber Resilience Act

Related NHI Mgmt Group resources: Software Supply Chain Levels Comparison, Secure Software Development Lifecycle (SSDLC) Guide, DevSecOps Guide and OT Security Standards Compared. This guide summarises secure development frameworks and the EU Cyber Resilience Act and is not legal advice.