2. Secure by design and default across a product’s life cycle

As highlighted in the ENISA report Baseline security recommendations for IoT in the context of critical information infrastructures (9), security must be considered throughout the entire product life cycle. Regardless of the production model used (V-model or agile), the following life-cycle processes require explicit security consideration to support product security.

• Requirements. As part of this process, user, business, functional and security requirements are determined. These requirements reflect the intended use of the product and will be translated into specifications that will guide design, development and maintenance/deployment decisions at later stages.
• Design. As part of the design process, the architecture and the design of the product are created. This process involves the creation of a set of documents that describe how the product requirements, including security requirements, will be translated into system specifications and essentially how the product will work.
• Implementation. As part of the implementation process, specifications and software design artefacts are implemented in the product.
• Verification : This process involves all necessary steps to verify that the developed product actually meets the identified requirements and design principles of the previous processes.
• Deployment. This process follows the acceptance of the product subject to successful testing as part of the previous processes – that is, it takes place after it has been approved for release. It involves integrating all necessary elements of the solution into the production environment and its deployment.
• Maintenance and disposal. Solutions deployed in production need to be constantly maintained to ensure the availability and integrity of the functionality provided. When the solution becomes obsolete, it is important to provide data erasure mechanisms that ensure secure disposal and preserve privacy management.

These processes are presented as groupings, not a mandatory sequential model. They may overlap, occur iteratively and be revisited throughout a product’s life cycle. For example, in agile environments, security requirements may be captured and progressively refined through backlog items, user stories, acceptance criteria and the definition of done.

Figure 1: Secure by design and default across a product’s life cycle

Figure 1 shows the relationships between the product life cycle, secure by design and default principles and risk management activities.

Risk management activities establish the security context by clarifying important considerations, including what needs to be protected, the threats of concern and the acceptable level of residual risk given the product’s intended purpose and security impact. Secure by design and default principles translate this context into practical security decisions that are applied throughout the processes of the product life cycle, from requirements through to end of life.

Risk management activities should be revisited in response to changes or events arising during the product life cycle. Similarly, while the product life-cycle processes are presented sequentially, both the life cycle and the application of secure by design and default principles across the processes are inherently iterative. Events or findings in later processes, such as testing results, deployment in new environments, incidents, discovered vulnerabilities or the implementation of new features, often require re-entry into earlier life-cycle processes.

Frameworks such as the OWASP software assurance maturity model (SAMM) (10) may be used to organise and mature security activities across the software life cycle. Its threat assessment and security requirements practices provide one example of how identified threats can inform testable security requirements. For SMEs, especially those operating with rapid iterations, the key is to keep life-cycle processes lightweight, risk driven and automation first:

• use small, reusable artefacts (one-page context, simple diagrams, checklists);
• prefer automated controls in continuous integration and continuous delivery (CI/CD) over manual reviews, reserving deep reviews for high-risk changes;
• introduce fast security gates aligned with existing agile ceremonies (definition of ready/done, pull request (PR) checks, release checklist).

Table 1: Cybersecurity activities during the product life cycle for SMEs

process

context and

assumptions, short

security requirements

checklist (including

secure defaults)

secrets, logging).

dependency hygiene; protect secrets; require review

for security-sensitive changes; configure automated

static application security testing (SAST) /

dependency scanning as part of CI environments

(agile /DevOps/DevSecOps).

scanning, basic dynamic application security testing

(DAST) where relevant); ensure default configuration

is validated; run targeted penetration testing when

potential risk triggers are hit (e.g. in the case of a

substantial modification). Run automated tests with

high coverage that include security-relevant negative

tests (verifying that what shouldn’t happen doesn’t

happen). Note that security verification should be

integrated into developer workflows and CI pipelines

as early as possible (following the ‘shift left’ principle).

updates

( a ) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README .

Risk management activities provide the foundation for implementing secure by design and default across the product life cycle. They ensure that security decisions are based on an informed and shared understanding of what needs to be protected, from whom and under what constraints.

In this report, ‘risk management’ concerns cybersecurity risks affecting the product and the users, operators, customers, data, services and systems that depend on it, taking into account the product’s intended purpose and reasonably foreseeable use. It does not refer to the manufacturer’s commercial or reputational risk.

These activities establish the context within which secure by design and default principles are applied. Their outputs directly informs:

• security requirements and architecture decisions;
• default configuration and ‘out of the box’ hardening;
• prioritisation of controls and assurance activities (e.g. testing depth, review gates);
• acceptable trade-offs inherent to the product’s intended use and deployment context;
• the ongoing operational security posture, including patching and end-of-life handling.

Risk management is typically initiated early, but it must be iterative: revisited at defined life-cycle gates (e.g. major release, supplier change, new deployment context) and triggered by significant events (e.g. newly disclosed vulnerabilities, threat shifts, incident learnings). Examples of risk management activities directly supporting secure by design and default decisions include:

• product context definition, including intended purpose, operating environment, users, data processed, and constraints
• establishing risk acceptance criteria, expressed as simple and practical guidelines to support consistent decision-making;
• high-level risk assessment focused on threat modelling, key assets, trust boundaries and risk treatment decisions.

Risk assessments should also be informed by evidence from deployed products, including customer and researcher reports, incident investigations, observed exploitation patterns and proportionate telemetry, where available and appropriate.

This report does not aim to define or replace a formal risk management framework. Rather, it aims to highlight common risk management activities and outputs that feed security decision-making.

To support SMEs, the following list is a sample set of activities that can drive secure by design and default decisions without creating heavy processes. The purpose of these activities is to translate product context and credible threats into testable security requirements, prioritise the relevant playbooks and determine the appropriate depth of controls and assurance activities, rather than applying every practice uniformly.

Table 2: Risk management activities for SMEs

dependencies (cloud, mobile app, third

parties).

Asset and adverse effect identification

modelling

conditions (e.g. misuse of software updates,

unauthorised administrative access and

exploitation of default credentials are not

acceptable) and establish criteria for

accepting residual risk. For example, the

accepted level of residual risk should not

undermine the essential cybersecurity

requirements, given the product’s intended

purpose and reasonably foreseeable use.

Security requirements baseline

include a formal pre-release gate to verify

compliance with the requirements defined

during the above activities. This review

should confirm checklist met, defaults

verified, known vulnerabilities triaged, high

risks treated / accepted with rationale;

decide go/no-go.

Change-triggered reassessment

Risk assessments can also support product-specific implementation of applicable cybersecurity requirements, assessment and treatment of identified vulnerabilities and evaluation of the security impact of significant changes to a product.

Threat modelling is a structured activity that supports security decision-making and may inform risk assessment by helping teams identify credible threats and attack paths. Combined with the product context and an appropriate prioritisation method, the outputs can help in selecting appropriate security requirements and controls, including secure by default settings.

One commonly used approach to identifying and categorising security threats is STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege) (11). STRIDE is presented in this report as an illustrative example, but other suitable threat-modelling approaches may also be used(12).

Threat modelling should align with widely accepted threat-modelling principles (13), recognising that it is a collaborative and iterative activity focused on understanding and reducing real security risks, rather than simply producing documentation artefacts. Common anti-patterns to avoid include treating threat modelling as a one-off compliance exercise, over-engineering models that do not influence design or secure by default decisions and failing to review the model following substantial product modifications or changes in the threat landscape. For products incorporating artificial intelligence (AI) / machine learning (ML) components, threat identification should also consider relevant AI-specific attack patterns, such as prompt injection, model poisoning and adversarial inputs (14).

For SMEs, particularly those developing products intended for non-critical or lower-risk environments, the objective is not exhaustive analysis; it is a minimum viable model that is fast to produce, easy to refresh and tightly coupled to delivery (architecture decisions, default configuration and release gates).

A lightweight threat-modelling exercise can be organised around four questions (Shostack’s four-question framework) (15).

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good enough job?

Table 3 provides an illustrative example of how these questions can be translated into practical activities and deliverables for SMEs.

Table 3: Threat modelling for SMEs

Define scope, Time-box a short scoping stage to One-page (or equivalent assumptions and make the exercise decision ticket/wiki) ‘Threat model security objectives focused. Capture what is in and out scope and objectives’ note, of scope (e.g. devices, apps, cloud covering: services, admin tools), the

• purpose (what decisions deployment context(s) and the this will drive); assumptions and constraints you ▪ scope boundaries are working under (e.g. ‘device may (components and be physically accessible’, ‘customer environments); network is untrusted’, ‘cloud APIs ▪ assumptions/constraints;
• security objectives and are internet-exposed’, ‘advanced ‘crown jewels’ (what must user capabilities’). Then state the not fail). security objectives that matter for this product (e.g. confidentiality, integrity, availability, plus privacy/safety if applicable).

the system that answers Shostack’s

core question, ‘What are we

working on?’ This may be an

architecture diagram, a data-flow

diagram or another suitable

representation. It should show the

main components, data stores,

external entities, key data flows,

entry points and trust boundaries in

sufficient detail to assess exposure.

Complementary techniques, such

as misuse cases or attack trees,

may also be used where helpful.

Consider reusing the architecture

and trust-boundary diagram

developed during the design phase

described in Table 1.

Mark trust boundaries Annotate the diagram with (a) trust Diagram showing: and privilege paths; boundaries (a) (boundaries between

• trust boundaries (internet– identify key assets environments with different security back end, device–cloud, properties) and (b) the highest- user–admin, tenant– privilege operations (e.g. firmware / tenant); OTA updates, remote admin, key ▪ privileged paths (updates, provisioning, identity issuance). auth, key management, admin actions); This is the step that turns
• top assets architecture into security-relevant (credentials/keys, sensitive architecture.

data, device control functions, availability).

of the answers to the question

‘What can go wrong?’, mapped to

entry/exit points, data flows and

trust boundaries (e.g. ‘credential

stuffing → account takeover →

remote control’, ‘malicious update’,

‘API authorisation bypass’, ‘man-in-

the-middle attacks during

onboarding’). Prioritise them using

a lightweight, documented method

appropriate to the product. This

might take into account impact,

likelihood, plausibility, exploitability

and exposure or use predefined

severity criteria. OWASP (b)

describes this as threat

identification and ranking as a core

step in most threat-modelling

approaches.

Define mitigations and Next, focus on ‘What are we going Controls, defaults and secure defaults, verify to do about it?’ For each top verification checklist, including: their effectiveness and threat, specify the mitigation

• Control/default decision set refresh triggers strategy, the required control(s) and for each top threat; the secure by default settings that ▪ test/verification mapping the product should ship with (e.g. (automation first); ‘admin interface disabled by ▪ explicit refresh triggers default’, ‘no default passwords’, (so that the model stays current). ‘signed updates enforced’, ‘least-privilege roles’, ‘authentication attempts rate-limited’). Then map each control to how it will be verified (e.g. CI checks, tests, configuration validation, release gates), which will help to answer the question ‘Did we do a good enough job?’ Finally, define the triggers that require rerunning the model (e.g. a new internet-exposed interface, a new auth model, new sensitive data, a new critical dependency, a major architecture change).

( a ) https://owasp.org/www-community/Threat_Modeling_Process ;. ( b ) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html .

A practical starting point could be to identify a small number of the highest-impact adverse-effect scenarios for users, operators or other affected parties and a manageable number of credible threat scenarios (e.g. the top 5 to 10) that could lead to them. These scenarios should be prioritised based on impact and likelihood. As part of their release review, teams should determine whether product changes affect the scenarios, assumptions or controls. Where products are intended for higher-risk or critical use cases, depending on the product’s intended use and associated risks, a more comprehensive analysis will be required.

Lightweight threat modelling does not necessarily require special threat-modelling expertise. Product expertise, on the other hand, is essential, because an accurate understanding of the product, its intended use and its deployment context is the foundation of a useful threat model. However, specialist security expertise is likely to be needed for higher-risk products or more complex threats.

Threat-modelling outputs can vary depending on aspects like the product’s scope, the assumptions, the methodology selected and analyst judgement. These inputs should be documented and applied consistently, to increase repeatability and support review.

Threat modelling and risk assessment should be revisited throughout the product lifecycle. For example, reviews could be performed at initial product design, implementation of the technical architecture, and verification, validation, maintenance and operation, where discovered vulnerabilities and field evidence can inform subsequent assessments.