+4. Playbooks
---+4.1 Trust boundaries and threat modelling
---+4.2 Least privilege
---+4.3 Strong identity and authentication architecture
---+4.4 Attack surface minimisation
---+4.5 Defence in depth
---+4.6 Open design
---+4.7 Life-cycle management
---+4.8 User-centric design
---+4.9 Secure coding and verification practices
---+4.10 Logging, monitoring and alerting
---+4.11 Configuration and change management
---+4.12 Incident response and recovery
---+4.13 Vulnerability and patch management
---+4.14 Supply-chain controls
---+4.15 Minimisation of default services
---+4.16 Restrictive initial access
---+4.17 Secure communication by default
---+4.18 Unique device identity and secrets by default
---+4.19 Mandatory security onboarding
---+4.20 Automated maintenance and updates
---+4.21 Transparent security posture
---+4.22 Secure recovery and ownership life cycle
---+4.23 Progressive adoption of the playbooks
------+4.23.1 Establish context and priorities
------+4.23.2 Establish a foundational engineering baseline
------+4.23.3 Broaden and strengthen implementation

4. Playbooks

These playbooks provide a practical, lightweight way for small and medium-sized manufacturers and product teams to implement secure by design and secure by default principles without creating a heavy governance burden. Each playbook distils a single security principle into a one-page, execution-focused guide that teams can apply repeatedly across releases and product lines.

The intention is to translate security principles from abstract aspirations into concrete engineering and operational actions, with clear expectations, verifiable outcomes and a consistent definition of done for security. Each playbook follows the same format to make adoption fast and repeatable.

Principle. The security concept being implemented.
Objective. What the principle is trying to achieve and what failure modes it reduces.
Checklist. The highest-impact actions to implement (designed to be achievable in lean teams).
Minimum evidence. The smallest set of artefacts/logs/configurations that demonstrate that the checklist has been implemented.
Release gate. A copy and paste set of pass or fail criteria that can be used in a release review (or CI/CD). Teams should apply the criteria relevant to the release and confirm that the controls continue to operate as intended where the release could affect them.

This structure is deliberately aligned with how SMEs operate: short cycles, shared responsibilities, limited specialist capacity and a need for guidance with a high signal-to-noise ratio. Unless stated otherwise, the actions in the playbooks are directed at manufacturers and teams acting on their behalf. References to users and operators describe product capabilities, information or actions that manufacturers should enable or support.

Developers and manufacturers should consider the following guidance when using the playbooks.

Treat each playbook’s release gate as a standard agenda item in release readiness
Implement the minimum evidence as repository artefacts and CI outputs wherever possible.
Use the product changes, threat model and risk assessment to determine which release-gate criteria require verification. Unchanged controls may be recorded as not affected.
Reuse the same evidence across playbooks where appropriate. For example, a single SBOM, scan result or release record may satisfy related evidence requirements and release-gate criteria for more than one playbook.
Allow exceptions only with a documented rationale, owner and review date.
Refresh playbooks periodically based on incident learnings, vulnerability trends and product changes.

It is important to note that the items listed under ‘Minimum evidence’ do not necessarily require separate documents or artefacts. A single item of evidence may support several playbooks. Organisations should reuse existing engineering records wherever possible, including architecture diagrams, repository files, configuration records, issue-tracking tickets, test results, SBOMs, CI/CD outputs and release records.

The contents of this section should be treated as a baseline rather than a final state. As products evolve, risks change and new features are introduced, the content should be reviewed and updated to ensure that secure by design and secure by default remain effective over time.

The playbooks can be adopted progressively, prioritising those most relevant to the product’s risks, intended use and development context. Progressive adoption does not imply delaying any applicable requirements or controls, including those arising from legal obligations under the CRA. A suggested approach is provided at the end of this section.

1. Apžvalga

4.1 Trust boundaries and threat modelling

Principle (secure by design)	Secure architectures make trust explicit rather than assumed. Trust boundaries define where data, identities and execution contexts cross from a more trusted domain to a less trusted one (or vice versa).
Objective	Ensure that the system’s architecture and data flows are understood, trust assumptions are explicit and the highest-risk attack paths are identified early, so that security controls and secure defaults are designed in, not retrofitted.

Checklist

Draw the system (one diagram)	Include users/admins, device/app, back-end services, APIs, data stores, third parties. Show key data flows and entry points (APIs, admin UI, OTA/update channel, local ports).
Mark trust boundaries and privileged paths	Identify where trust changes (internet–back end, tenant–tenant, device–cloud, user– admin). Highlight high-privilege flows (auth, key management, updates, admin actions).
List critical assets	For instance, list credentials/keys, customer / personally identifiable information, payment tokens, device control functions, availability, audit logs, data, source code and the IDE.
Identify and prioritise top threats	Map threats to the relevant entry/exit points, data flows, assets and trust boundaries, for example account takeover, malicious updates, API authorisation bypass, man-in-the-middle attacks and the tampering with, replay of or injection of fabricated or stale data and commands. Assign a high, medium or low priority using a documented method appropriate to the product, such as assessing impact, likelihood, plausibility, exploitability and exposure.
Define mitigations, secure defaults and verification	For each top threat: required controls and default configuration (deny by default, authn/authz, segmentation, signed updates, rate limits). Map each control to a verification method (tests, CI checks, config validation). Define refresh triggers (new interface, auth change, new sensitive data, new critical dependency, major architecture change).

Minimum evidence

One architecture/data-flow diagram with trust boundaries and entry points (stored in repo/wiki)
Top threats list (e.g. the top 5 to 10 threat scenarios) with H/M/L priority and owners
Control/default mapping for each top threat (what control, where enforced, how verified)
Verification evidence: CI outputs or test results for key negative tests (unauthorised calls fail)

Release gate

Diagram updated for this release (components, flows, dependencies reflect reality)
Trust boundaries and privileged paths clearly marked
Top threat scenarios reviewed; high risks have mitigations or documented exceptions
Secure defaults confirmed for new/exposed interfaces (deny by default, least privilege)
Verification in place: at least one negative test per critical boundary / privileged path (unauthorised access is denied)
Threat model refresh triggered if any of the following are relevant: new API/interface, auth model change, new sensitive data, major dependency/supplier change, OTA/update changes, major architecture change.

4.2 Least privilege

Principle (secure by design)	Every user, service and process operates with the feasible minimum permissions needed to do its job – no more and for no longer than necessary.
Objective	Reduces unauthorised access, limits blast radius, blocks lateral movement and prevents permission creep.

Checklist

Define minimum viable permissions for each role/service	List key roles (user, support, admin) and key services (API, provisioning, updates). For each, define allowed actions (read/write/admin) and resources (APIs, tables, buckets).
Use unique identities (no shared admin)	One identity per service (service account/workload identity) , applicable to both web services and services running on a device. No shared admin users/keys; separate dev/test/prod identities.
Default-deny and explicit allow lists	Deny by default; allow only required API methods, data access and network paths. Restrict service-to-service access to specific interfaces.
Time-bound admin access (JIT) + attribution	Named accounts + MFA for admins (all human users if possible). Temporary elevation for privileged actions; break-glass is separate and monitored.
Automate privilege hygiene	Monthly (or at each release), flag broad privileges and unused permissions/tokens; remove or time-limit exceptions.

Minimum evidence

Access model exists: for example, a short table “Role/Service, allowed actions, resources” stored in repo/wiki and kept current.
No shared admin: IAM inventory shows unique service identities; no reused production admin keys.
Deny works: automated negative tests prove unauthorised API/data access is blocked for each critical service.
Admins are accountable: logs show who performed privileged actions; elevation expires automatically.
Creep is controlled: recurring report flags unused/broad permissions; removals/exceptions are tracked, with owner and expiry.

Release gate

Unique service identities; no shared production admin keys
Default-deny posture; only required paths enabled
Admin access uses MFA and is time bound and logged
Automated authorisation tests run verifying correct access restrictions for critical privileged functions
Privilege review run; exceptions owned and time limited

4.3 Strong identity and authentication architecture

Principle (secure by design)	Design identity and authentication as a core part of the architecture. Use authoritative identity mechanisms for users, devices, services and administrators across interfaces.
Objective	Prevent impersonation and unauthorised access.

Checklist

Define authoritative identity sources	Identify and document the authoritative identity source (i.e. a system that acts as the single source of truth for creating, authentication/authorisation, and revoking identities) for users, devices, services and administrators.
Use unique identities for all actors	Assign a unique identity to each user, device, service and administrator, prohibiting shared accounts/credentials, especially for administrative and service access.
Apply authentication across all interfaces	Enforce authentication/authorisation on all access paths, including user interfaces, APIs, device-to-cloud communication and management interfaces.
Strengthen authentication for high-risk access	Require stronger authentication for privileged actions and sensitive operations (e.g. MFA, device binding, or cryptographic credentials).
Manage sessions and credentials securely	Ensure that sessions are time limited, bound to identity and invalidated on logout or credential change. Rotate, revoke and expire credentials automatically when no longer needed or when compromise is suspected.

Minimum evidence

Authoritative identity sources defined: a diagram or table exists showing the identity source for users, devices, services and administrators.
No shared identities: identity inventory shows unique identities, no shared production accounts or credentials.
Authentication enforced: configuration or test evidence shows that all interfaces enforce authentication or are explicitly defined as public with appropriate protections applied. Network location or reachability alone is not treated as authentication, unless explicitly justified by the product context and risk assessment and supported by appropriate compensating controls.
Strong auth for privileged access: policy or configuration shows that MFA or equivalent is enforced for administrative or sensitive actions.
Sessions and credentials controlled: configuration or logs show session expiry, revocation on logout or credential change, and credential rotation or expiry in place.

Release gate

Authoritative identity sources defined and documented
Unique identities enforced; no shared production accounts or credentials
Authentication required on all access paths (UI, APIs, device-to-cloud, management interfaces)
Strong authentication enforced for privileged or sensitive actions
Sessions and credentials are time limited, revocable and expire automatically

4.4 Attack surface minimisation

Principle (secure by design)	Expose only what is strictly necessary. Remove or disable all unnecessary code, services, interfaces, protocols and dependencies by default.
Objective	Reduce the likelihood and impact of compromise by eliminating unnecessary entry points and limiting attacker options.

Checklist

List exposed interfaces	Identify all externally reachable APIs, ports, local interfaces (HMI), protocols, admin endpoints and update channels. Remove or disable anything without a clear, current justification.
Enforce default deny	Close all ports, APIs and interfaces by default. Explicitly allow only what is required for production.
Remove development and diagnostic functionality	Remove debuggers, test endpoints and debug modes from production builds. Remove development features.
Minimise dependencies	Remove unused libraries, SDKs and optional components from final builds. Remaining libraries should be verified for authenticity and integrity. Use the smallest possible operating system, runtime or firmware configuration that supports the product’s intended function.
Continuously monitor for legacy exposure	Continuously review exposed interfaces and dependencies. Update/remove deprecated APIs, old protocols and unused resources.
Minimise data collection, processing and retention	Collect, retain and store only the personal or sensitive data necessary for the product’s intended purpose and securely delete it when no longer required.

Minimum evidence

Exposure inventory exists: a maintained list of externally reachable interfaces (APIs, ports, protocols, admin interfaces, update channels) is stored in the repo or product documentation.
Default deny enforced: network rules, gateway configuration or device settings show that only explicitly required interfaces are enabled in production.
Minimal build verified: build configuration, manifest, package list or firmware contents show that only required components are included.
No dev or diagnostic tooling shipped that might enable exploitation: inspection of production artefacts confirms absence (or verification that they cannot impact security) of shells, debuggers, compilers, test interfaces and diagnostic utilities.
No legacy exposure: release notes, ticket or checklist entry confirms that exposed interfaces and dependencies were reviewed and any unused or legacy elements removed.
Data inventory and retention record: data inventory with purposes, retention periods and deletion methods is kept.

Release gate

Exposed interfaces reviewed; only required APIs, ports, protocols and management interfaces enabled
Default-deny posture confirmed; no unintended network paths or interfaces exposed
Production build is minimal; unused libraries, services and optional components removed
No development or diagnostic tools present in production unless there is evidence that it cannot impact security
Attack surface review completed for this release; deprecated or legacy interfaces updates/removed
Unnecessary data processing has been removed and required deletion mechanisms verified

4.5 Defence in depth

Principle (secure by design)	Apply multiple layers of security so that the failure or bypass of a single control does not result in full compromise.
Objective	Reduce the impact of security failures by layering independent controls that slow attackers, increase detection and prevent single points of compromise.

Checklist

Layer controls around critical assets	Identify the most sensitive assets (e.g. credentials, control functions, customer data). Ensure that more than one independent control protects each asset. Where critical data or commands cross trust boundaries, consider integrity and freshness controls that remain effective if another protection layer, such as transport security, is bypassed.
Assume control failure and design for containment	Design systems so that bypass of one control does not grant unrestricted access.
Enable detection at multiple layers	Generate security-relevant logs at key layers (identity, network, application, data). Ensure that failed and suspicious actions raise alerts and are not silently blocked.
Use diverse and independent controls	Avoid relying on multiple controls that share the same technology, identity source or trust assumption.
Slow attackers and enable response	Apply controls that increase attacker effort and time (rate limits, step-up authentication, staged access). Ensure that response mechanisms exist to contain or isolate compromised components when alerts are triggered.

Minimum evidence

Layered protection mapped: a simple table or diagram showing critical assets and the multiple security controls protecting each (stored in repo/wiki).
Independent controls confirmed: configuration or design notes showing that layered controls do not rely on the same identity source or enforcement point.
Multilayer logging enabled: log configuration or sample logs showing security events recorded across controls.
Alerts and response defined: alert rules or playbook reference showing how suspicious activity is detected and the associated containment or response action.

Release gate

Critical assets have more than one security control applied and the layering is documented.
Layered controls are independent; no single identity source or enforcement point is a single point of failure.
Security-relevant events are logged at multiple layers
Alerts are in place for suspicious activity and a response action exists

4.6 Open design

Principle (secure by design)	Systems should not depend on secrecy of design or hidden behaviour for protection. Security controls should remain effective even if an adversary understands how the system operates.
Objective	Ensure that the product’s security does not depend on the secrecy of its design or implementation details (‘security through obscurity’). Open design makes security properties reviewable, testable and maintainable.

Checklist

Document security-relevant design decisions	Keep a short security design note covering trust boundaries, auth model, cryptographic usage, update mechanism, logging/audit approach and secure defaults. Record the rationale for ‘why this control/protocol/library’.
Prefer open standards and proven building blocks	Use standard, widely reviewed protocols and libraries (e.g. TLS, OAuth/OIDC, JWT with clear constraints, signed updates). Avoid proprietary crypto, “home-grown” protocols, and undocumented encodings for security-critical flows.
Make interfaces and security expectations explicit	Document APIs, authentication/authorisation requirements, error handling, rate limits and supported configurations. Provide a secure configuration guide (outlining what must be enabled and disabled in production).
Enable review and disclosure	Establish a vulnerability disclosure channel (security contact, intake process, basic triage/response targets). Encourage internal peer review for security-sensitive changes (to auth, updates, crypto, boundary-crossing interfaces).
Maintain transparency of components and changes	Maintain, publish and sign an SBOM (at least for customer-facing builds) and track third-party components. Keep a security changelog / release notes for security-impacting fixes and default-setting changes.

Minimum evidence

Security design note (1–3 pages), covering boundaries, auth, crypto choices, update path, logging, secure defaults
API + security requirements documentation (authn/authz, rate limits, data-handling expectations)
Secure configuration guide (production hardening defaults, required settings)
Vulnerability disclosure process (public email / web page or customer-facing channel; triage ownership defined)
SBOM (exported file or tool output) + dependency -tracking approach
Security-sensitive PR review rule (CODEOWNERS file, repo policy or checklist evidence)

Release gate

Security design note updated for any architectural/security-relevant change (auth, crypto, update path, trust boundaries)
No custom/proprietary crypto or undocumented security-critical protocols introduced
API/security documentation updated (auth requirements, scopes/roles, rate limits, secure defaults)
Secure configuration guide updated; defaults validated for new/exposed interfaces
SBOM generated for the release and stored/published per policy
Vulnerability disclosure channel tested (contact works) and ownership/triage defined

4.7 Life-cycle management

Principle (secure by design)	Security responsibilities extend beyond initial development. Components must be maintained, updated and eventually retired in a controlled manner.
Objective	Ensure that security is maintained throughout the product’s full life cycle, from requirements and design through to deployment, maintenance and end of life, so that security does not degrade over time.

Checklist

Define support commitments and life-cycle states	Publish (internally or externally) life-cycle states: active, maintenance, end of sale, end of support, end of life. Define minimum support windows and internal guidelines for vulnerability triage and patch release timelines (e.g. critical vulnerabilities triaged in 48 hours; fixes released within X days where feasible).
Make the product updatable and recoverable	Implement a secure and transactional update mechanism (authenticated updates, integrity protected, rollback/recovery plan). Ensure safe failure modes (do not brick devices; provide fallback/rollback where practical). During maintenance or recovery modes, restrict functionality and privileges to the minimum necessary to support update and recovery operations.
Operate vulnerability and patch management	Track vulnerabilities from third-party components, internal findings and customer reports. Maintain an SBOM (at least for each release) and a dependency update cadence. Triage, prioritise and document risk decisions (fix, mitigate, accept with expiry date).
Monitor, log and handle incidents	Enable security-relevant logging (auth events, admin actions, update events, boundary-crossing requests). Define minimum incident response steps, for instance detection, triage, containment, remediation, customer communication
Learn from deployed products	Collect evidence on how products are deployed and used, such as customer feedback, support cases, vulnerability reports, incident findings and privacy-preserving telemetry where appropriate. Review findings, including the results of root-cause analyses where applicable, and update the product context, risk assessment, threat model and secure defaults as necessary.
Plan secure decommissioning and disposal	Provide data erasure mechanisms and guidance (factory reset, key revocation, account deprovisioning). Revoke credentials/keys when devices/users/services are deactivated. Ensure that end-of-life guidance includes what security updates cease and what customers must do.

Minimum evidence

Life-cycle policy: lifecycle states + support window + patch SLAs (1 page).
Update/release process: secure update approach and rollback/recovery notes
Vulnerability management log: intake, triage, prioritisation, disposition, owner, dates (ticket board or spreadsheet)
SBOM: SBOM generated in a machine-readable, widely adopted standard format (e.g. SPDX or CycloneDX) and stored with the release
Monitoring and logging: security logging baseline + sample logs showing admin/auth/update events
Field feedback record: summary of relevant operational evidence reviewed, deviations from deployment assumptions identified and resulting actions
Decommissioning checklist: data wipe/reset, credential/key revocation and customer guidance

Release gate

Support status and life-cycle state for this release are clear (active, maintenance, etc.)
Secure update path validated (integrity/authentication checks, rollback/recovery documented)
Vulnerability triage completed for known issues (including third-party dependencies); decisions recorded (fix/mitigate/accept with expiry)
SBOM generated (or dependency inventory updated) and stored for the release
Security logging verified for critical events (authentication, admin actions, updates)
Decommissioning actions defined for components introduced/changed (e.g. reset, wipe, key revocation)
Any accepted residual security risk has an owner and review/expiry date

4.8 User-centric design

Principle (secure by design)	Security mechanisms must be usable and understandable even for everyday users.
Objective	Ensure that security controls and secure defaults are usable, understandable and aligned with real user workflows, so that security outcomes do not depend on expert behaviour.

Checklist

Design secure defaults that require minimal user action	Ship with the safest practical settings enabled (e.g. least exposure, secure communications, logging enabled). Avoid optional security for critical protections; make insecure modes explicit and gated.
Make set-up and onboarding safe and simple	Provide a guided first-run experience with clear security steps (e.g. change initial credentials, pair securely, enable updates). Minimise manual configuration for sensitive settings; prefer automated secure provisioning.
Use clear, actionable security messaging	Write user-facing warnings and error messages that explain what happened, the impact and what to do next. Avoid vague messages (‘failed’) or blame-the-user language; include remediation steps.
Provide least-friction access management	Prefer role-based access and simple permission models that match user roles (e.g. admin, operator, viewer). Support safer auth options where feasible (e.g. MFA for admins, device identity, short-lived tokens). Remove/limit insecure recovery paths; make account recovery robust.
Validate usability to prevent insecure workarounds	Run quick usability checks on key security flows (onboarding, password reset, admin tasks, updates). Use support tickets and pseudonymised telemetry (where appropriate) to detect confusion and misconfiguration trends.

Minimum evidence

Secure defaults list (what ships enabled and disabled, with rationale)
Onboarding / security set-up guide (short, step-by-step, including credentials and update steps)
Roles/permissions model (roles defined + what each can do)
User-facing security message catalogue (examples of warnings / error messages and text outlining required remediation measures)
Usability validation notes (at least three to five users or internal proxies) covering the top security flows, plus resulting fixes

Release gate

Secure defaults reviewed and validated (no critical protections disabled by default)
No default admin credentials active; onboarding enforces safe initial set-up
Admin/security-critical actions have clear UX (confirmations, guidance and safe recovery paths)
Roles and permissions match real user workflows; privilege escalation is explicit and auditable
Security warnings / error messages are actionable (what, why, how to fix) and documented
Basic usability check completed for key security flows (onboarding, admin tasks, recovery, updates); issues tracked/fixed or accepted with owner + date

4.9 Secure coding and verification practices

Principle (secure by design)	Developers should follow established secure coding standards to prevent common vulnerabilities.
Objective	Reduce common, high-impact vulnerabilities by eliminating relevant weakness classes through architectural and technology choices, where feasible, and by standardising how remaining risks are addressed in code, review and testing.

Checklist

Eliminate vulnerability classes by construction	Prefer architectural and technology choices that prevent relevant vulnerability classes from arising, such as memory-safe languages for buffer overflows, parameterised data-access APIs for SQL injection and frameworks with context-aware output encoding for cross-site scripting. Where elimination is not feasible, identify the remaining vulnerability classes and apply appropriate coding, review, testing and containment controls.
Adopt a secure coding baseline (language/framework specific)	Define must-follow rules for your stack (e.g. on input handling, auth checks, error handling, crypto usage, logging). Ban unsafe patterns (e.g. string-built SQL, eval-like functions, disabling TLS verification).
Validate inputs and encode outputs	Centralise validation (schemas, allow lists, length/range checks). Encode output by context (HTML/JSON/SQL); avoid mixing data and commands.
Use safe dependency and secrets practices	Pin and regularly update dependencies; remove unused packages. Secrets (e.g. API keys, tokens, credentials) must never be stored in source code or committed to source repositories. Secure secret management solutions should be used instead. Generate and store an SBOM for each release (or a dependency inventory at minimum).
Make security-sensitive changes reviewable	Clearly define and document roles for each stakeholder involved in the CI/CD pipeline (e.g. developer, support, administrator, integrator, CI runner). Protect critical branches to prevent direct commits and history rewriting. Prohibit force push on protected branches to prevent history rewriting and preserve auditability. Require peer review for changes touching authn/authz, boundary-crossing APIs, crypto, update mechanisms or deserialisation and for any new external exposure. Use PR checklists and CODEOWNERS files for sensitive areas. Apply the same review requirements to AI-generated or AI-modified code as to human-written code.
Automate detection in CI/CD	Run SAST and dependency scanning on each PR; fail builds on critical findings. Add targeted unit/integration negative tests (unauthorised access denied; injection attempts fail). Add basic fuzzing or property-based testing for high-risk parsers/inputs if feasible. AI-generated or AI-modified code should go through the same SAST, dependency and secrets checks as human-written code.

Minimum evidence

Design evidence: record of relevant vulnerability classes considered and the architectural or technology choices used to eliminate them by construction
Secure coding standards (one or two pages or a repo file) for your stack and a banned patterns list
PR checklist / CODEOWNERS file for security-sensitive modules
CI pipeline evidence: SAST and dependency scan results for the release
Secrets controls: proof that secrets are not in repo (pre-commit secret scanning results) and secrets manager usage
Test evidence: at least a small suite of negative tests for critical endpoints/inputs

Release gate

Relevant vulnerability classes have been eliminated by construction where feasible; where not feasible, appropriate preventive and verification controls are in place.
A secure coding baseline exists for the stack and is referenced in the repo
SAST and dependency scanning run in CI; critical issues fixed or covered by a documented exception (with owner and expiry)
Secret scanning enabled; no secrets committed; rotation performed if exposure occurred
Security-sensitive changes were peer reviewed (auth/authz, crypto, parsers, external interfaces)
Negative tests run on critical endpoints (unauthorised access denied; injection attempts fail)
Dependencies reviewed for high/ critical vulns; patch/mitigation plan recorded for any accepted risk

4.10 Logging, monitoring and alerting

Principle (secure by design)	Systems should generate appropriate security-relevant logs, retain them for a defined period and protect them from tampering, so that they can support investigation and compliance needs.
Objective	Provide sufficient visibility to detect misuse, investigate incidents and maintain system integrity over time. The focus is on a small set of high-signal security events, reliable log retention and actionable alerts that do not overwhelm teams.

Checklist

Define the “must-log” security events	Authentication: login success/failure; MFA events; token issuance/refresh/revocation. Authorisation: access denied, privilege or role changes, admin actions. Boundary events: external API calls, device onboarding or pairing, OTA/update events. Data or security changes: configuration changes, key or secret changes, user or service enabled or disabled. Do not log personal or secret data by default. In general, log only the bare minimum required to understand events in default log level
Standardise access and audit log structure and attribution	For access and authorisation logging, use consistent fields capturing who (actor), what (action or event type) and when (timestamp), with additional contextual fields as appropriate. Ensure that admin actions are attributable to a named identity (no shared accounts).
Centralise collection and protect log integrity	Central log store (SIEM/log platform or managed logging). Separate logs based on type and/or service. Restrict access to logs; separate duties and apply write-only permissions where feasible. Set retention targets (e.g. 30 days or 90 days, longer for archival material if required). Plan storage accordingly. Ensure time sync (NTP) across systems.
Implement actionable monitoring and alerts	Start with a small alert set (high confidence, high impact): repeated auth failures, new admin creation, privilege escalation, unusual API error spikes, updates failing, disabled logging, access to sensitive endpoints from new locations. Tune alerts to reduce noise (rate thresholds, suppression windows, environment filters).
Practice incident triage and response	Define on-call duties / ownership for security alerts. Document a minimal triage playbook covering: validate, scope, contain, remediate and communicate. Carry out a quarterly tabletop exercise or dry run for one common scenario (account takeover or API key leak).

Minimum evidence

Logging baseline: list of must-log events and required fields (one page)
Central logging proof: screenshot/export/config showing logs from key components arriving centrally
Retention setting: configured retention is in place and there is an access-control policy for logs
Alert catalogue: list of enabled alerts with thresholds and owners (initial set can consist of around 5 to 10 alerts)
Triage runbook: one-page steps and escalation contacts, plus one recent test (tabletop note)

Release gate

Must-log security events implemented for new/changed components (auth, admin, updates, boundary events)
Logs include attribution fields (actor, request/session ID, source) and are centralised
Log access restricted, retention configured, time sync verified
High-signal alerts enabled and assigned an owner (at least brute force events, new admin / role change, key/secret change, update failures)
Triage runbook exists and has been tested recently (tabletop exercise or test alert)
Logging/alerting exceptions are documented, with owner and review/expiry date

4.11 Configuration and change management

Principle (secure by design)	Secure operation requires configurations to be controlled, consistent and auditable. Baseline hardening standards should be defined and applied through repeatable mechanisms such as templates and infrastructure as code to reduce drift.
Objective	Prevent security regressions and outages by ensuring that system configuration is controlled, reviewable and reproducible and that changes are assessed for risk before reaching production. The priority is to eliminate ‘silent drift’, tighten defaults and make rollbacks reliable.

Checklist

Version and review configuration (treat it as code)	Store environment config, infrastructure templates and policies in version control. Require peer review for changes affecting exposure, identity/access, secrets, networking, logging and updates.
Harden defaults and prevent drift	Establish secure baseline configurations (deny by default where possible). Use automated checks to detect drift between desired and actual config (at least for critical settings).
Separate environments and limit privilege	Strict separation for dev/test/prod (accounts, projects, networks, credentials). Restrict who can deploy to prod; remove direct manual changes where feasible.
Implement change gating and rollback	Use CI/CD gates for config and infra changes (linting, policy checks, approval). Require a rollback plan for each production change (including config-only changes). Keep break-glass changes rare, logged and post-reviewed.
Track and assess security-impacting changes	Tag changes that affect external exposure, authentication/authorisation, crypto, update mechanisms, data classification or third-party integrations. Ensure that a lightweight threat/risk review is triggered when these tags apply.

Minimum evidence

Config versioned: repo location(s) for IaC, config, policies; PR review history
Baseline config: documented secure defaults and key settings (one page)
Drift detection: a scheduled job/report or tool output for critical config items
Deployment controls: proof that prod changes go through CI/CD (or change tickets) and are attributable
Rollback proof: last rollback test result or documented rollback procedure
Change log: record of security-impacting changes and associated approvals

Release gate

Production config/IaC changes are versioned and peer-reviewed (no untracked manual edits)
Secure baseline defaults applied; new components inherit baseline (network, IAM, logging)
Dev/test/prod separated (accounts, projects, credentials); least privilege enforced for deployers
CI/CD gates applied to config changes (policy checks, linting); approvals recorded
Rollback plan exists for this release; rollback procedure tested recently or validated
Security-impacting changes tagged and reviewed (exposure, IAM, secrets, crypto, updates, integrations)
Exceptions (emergency changes) logged and post-reviewed, with owner and expiry date

4.12 Incident response and recovery

Principle (secure by design)	Developers must be prepared to respond quickly and effectively to security incidents that affect their products in the field, including vulnerabilities, compromised code, malicious updates and misuse of product functionality.
Objective	Detect, contain and recover from security incidents quickly while limiting customer impact and preventing recurrence. The priority is a clear playbook, defined ownership, fast triage and reliable restore/rollback, supported by the minimum logging and backup evidence needed to act decisively.

Checklist

Define roles, escalation and decision authority	Name an incident lead and backups. Define escalation thresholds, when senior management should be informed and who can approve customer communications, access elevation and emergency changes. Maintain an on-call/escalation contact list (internal + key suppliers).
Create a minimal incident runbook	Steps: detect, triage, contain, eradicate, recover, lessons learned. Include checklists for common scenarios (account takeover, leaked API key, ransomware/supply-chain alert, compromised device fleet).
Prepare containment controls	Make sure that it is possible to revoke/rotate credentials and keys quickly. Make sure that it is possible to disable accounts, block IPs, quarantine services/devices and roll back releases / config changes. Ensure that break-glass access exists, is logged and is time bound.
Ensure recovery capability	Backups are automated, tested and protected (immutability where feasible). Restore procedures are documented for critical systems (data, configs, secrets, device firmware if applicable). Define RTO/RPO targets appropriate to the business.
Exercise and improve	Run a lightweight tabletop exercise (30–60 minutes) quarterly on one realistic scenario. Record and review incidents, near misses and exercise findings. Track actions to closure and update risk assessments, threat models, runbooks, detections and controls as appropriate.

Minimum evidence

Defined roles: incident-response contact list + roles (owner, backups and escalation paths established).
Runbooks: one-page incident runbook and at least one scenario checklist.
Containment proof: documented steps and permissions to revoke keys, disable accounts and roll back deployments.
Backup/restore proof: backup configuration and one recent restore test result (or evidence of a successful restore).
Post-incident, near-miss or tabletop notes showing findings, actions and resulting improvements.

Release gate

IR roles and escalation contacts are current
Incident runbook exists and covers detect/triage/contain/recover with at least one common scenario
Containment actions are ready
Backups enabled for critical data/config; restore procedure documented and tested recently
Post-incident, near-miss or tabletop notes exist and are updated

4.13 Vulnerability and patch management

Principle (secure by design)	Manufacturers should establish practical, repeatable vulnerability and patch management processes and prioritise remediation according to risk. Manufacturers need a simple way for customers and researchers to report issues and an internal process to triage findings quickly and decide what needs urgent action.
Objective	Identify, prioritise and remediate vulnerabilities fast enough to reduce real-world exposure, across your code, dependencies, infrastructure and (if applicable) devices/firmware. The focus is a simple intake-to-fix workflow, clear SLAs and an update mechanism that makes patching reliable.

Checklist

Establish intake channels (do not miss issues)	Sources: dependency scanning, SAST/DAST results, advisories, customer reports, security emails, etc. Assign a single owner for triage and tracking.
Triage and prioritise consistently	Use a lightweight severity approach (e.g. critical, high, medium or low) plus ‘internet-exposed’ and ‘known exploited’ flags. Ensure awareness of applicable incident and vulnerability reporting timelines. Decide quickly: fix now, mitigate, accept (time bound) or defer (with rationale).
Patch dependencies and third parties proactively	Maintain a regular cadence (e.g. weekly or monthly) for dependency updates. Pin versions, remove unused dependencies and track transitive dependencies.
Fix, test and release with a secure process	Ensure that fixes are reviewed and tested; verify no regressions in authn/authz, input validation or critical workflows. For devices/IoT: ensure secure OTA/update path and safe rollback where feasible.
Communicate, learn and close the loop	Track affected versions, customers/environments and mitigation guidance. Publish security release notes or advisories as appropriate. Verify rollout completion and update the risk register. Establish an escalation process to assess applicable regulatory reporting obligations. Where proportionate, publish machine-readable advisories (e.g. CSAF), including structured information on whether specific products or versions are affected, such as through VEX. Analyse significant or recurring vulnerabilities, field reports, incidents and exploitation patterns to identify root causes. Feed the findings back into the risk assessment, security requirements and development practices.

Minimum evidence

Vulnerability tracking board / register: issue, severity, affected components/versions, owner, status, target date
Defined SLAs: for example, critical triage ≤ XX hours; remediation/release target ≤ X days (specify numbers that are realistic for you)
Scanning evidence: CI outputs for dependency scanning and SAST (and DAST if applicable)
Proactive dependency patches: SBOM or dependency inventory for each release (at minimum for shipped artefacts)
Patch release record: link from vulnerability ticket → PR(s) → tests → release version → rollout confirmation
Exception log: accepted risks, with owner and expiry/review date, and compensating controls (if any)
Field feedback and improvement record: recurring security issues or attack patterns, root causes identified where applicable, and the resulting risk, design or backlog actions.

Release gate

Dependency and SAST scans executed for the release; critical and high findings addressed or documented exception (with owner and expiry date)
SBOM (or dependency inventory) generated/updated and stored for the release
Known vulnerabilities affecting shipped components are triaged with severity information, owner and target date
Patch process validated: fix reviewed, tests passed, and release notes updated as needed
For internet-exposed components: mitigations or patches for critical- and high-severity issues are in place before release
OTA/update (if applicable) validated for secure delivery; rollback/recovery documented
Accepted residual risk is time bound and tracked to closure or review date

4.14 Supply-chain controls

Principle (secure by design)	Developers should protect product integrity without excessive process overhead, focusing on the points where a compromise would have the largest impact: code repositories, build systems, signing keys and the channels used to distribute updates.
Objective	Reduce the risk of compromise through third parties (software components, libraries, build tools, CI/CD, contractors, hosting providers and hardware/firmware suppliers) by establishing minimum, repeatable controls that improve visibility, integrity and accountability across what you buy, build and ship.

Checklist

Know what you depend on (inventory + SBOM)	Maintain an inventory of critical suppliers and third-party components, including externally sourced AI/ML models where relevant. Generate an SBOM per release (or minimum: dependency manifest snapshot) to improve visibility and response speed.
Control what enters your codebase	Pin dependency versions; require review for new dependencies and major upgrades. Pinning and lock files improve build repeatability but do not establish that the pinned component is trustworthy. New and updated dependencies still require appropriate review and security checks. Run dependency scanning in CI; block builds on critical- or high where feasible (or require explicit exception). Where proportionate, obtain dependencies through approved repositories or controlled registries and apply integrity, malware and policy checks before use. For externally sourced AI/ML models, record their source and version, verify their integrity and provenance, and assess relevant security risks before integration.
Harden the build and release pipeline (integrity of artefacts)	Restrict CI/CD permissions (least privilege), protect secrets and separate build and deploy roles. Sign release artefacts and, where proportionate, generate verifiable provenance describing how and from which inputs they were built. For higher-risk products, use isolated and ephemeral build environments, consider restricting build-time network access to approved sources and consider hermetic builds where feasible.
Set minimum supplier expectations (lightweight due diligence)	For critical suppliers, require a security contact / VDP, patch timelines and confirmation of secure development practices. Use a short questionnaire aligned with a recognised baseline (e.g. OWASP SCVS) rather than bespoke questions.
Plan for supplier failure	Identify single points of failure (key providers/components) and define fallbacks (alternate package source, vendor substitution plan, rapid disable/mitigation). Ensure that contracts and SLAs cover vulnerability notification and support windows (where possible).

Minimum evidence

Supplier + component inventory (top vendors, critical libraries/tools, hosting/build services), including externally sourced AI/ML models where relevant
SBOM (or dependency inventory) per release, stored with the release artefacts
CI results showing dependency scanning (and ideally secret scanning) executed on PRs/releases
Release integrity evidence: artefact signing and restricted CI/CD access (configs/screenshots/logs)
Supplier baseline checks for critical suppliers (a completed questionnaire or SCVS-aligned checklist)
Exception log for accepted supply-chain risks (with owners and expiry dates)

Release gate

SBOM (or dependency inventory) generated and stored for this release
Dependency scanning executed; critical- or high-severity issues fixed or covered by a documented exception (with owner and expiry date)
New dependencies/suppliers reviewed and approved (recorded in PR/ticket)
CI/CD and build secrets are protected; build/deploy permissions are least privilege and attributable
Release artefacts signed (and provenance captured where feasible / per chosen SLSA target)
Critical suppliers meet baseline expectations (security contact, vulnerability notification, support/patch commitments)
Supply-chain risk exceptions recorded, with owner and review/expiry date

4.15 Minimisation of default services

Principle (secure by default)	Disable non-essential features and services by default. Only the functionality required for the core operation of the product should be enabled by default.
Objective	Reduce the attack surface and ensure that products start in a hardened state, without relying on users to disable specific functionality.

Checklist

Define core functionality	Identify the minimum set of features and services required for the product to operate.
Disable non-essential features and services by default	Ensure that optional features and services are disabled by default.
Require explicit opt-in for additional functionality	Ensure that non-essential features and services can be enabled only through deliberate user action.
Explain security implications on enablement	Inform users of security risks when enabling optional features and services. Avoid enabling additional features and services without clear acknowledgement.
Review defaults on change	Reassess default-enabled features and services when new features are introduced.

Minimum evidence

Core features and services defined: documentation or configuration identifying which features and services are required by default.
Non-essential features and services disabled: default configuration or build artefacts show optional features and services and modules are off.
Explicit opt-in required: configuration or documentation shows how additional features and services must be manually enabled.
Security implications disclosed: documentation, UI text or configuration prompts show that users are informed of security implications when enabling non-essential features and services.
Defaults reviewed for this release: release notes, checklist or ticket confirms that default settings have been reviewed after changes.

Release gate

Only core functionality is enabled by default
Optional features and services are disabled unless explicitly enabled by the user
Users are informed of security implications when enabling non-essential features and services
No new features or services are enabled by default without review
Default configuration has been reviewed and confirmed for this release

4.16 Restrictive initial access

Principle (secure by default)	Ship systems in the most restrictive access state possible. Eliminate shared or default credentials and require a secure access set-up before any privileged or sensitive operations are allowed.
Objective	To prevent immediate compromise after deployment by ensuring that attackers cannot gain access through default or weak initial access.

Checklist

Eliminate shared default credentials	Do not ship products with universal usernames or passwords (e.g. ‘admin/admin’ or ‘root/root’).
Require unique credentials for each device or instance	Ensure that each device or instance has unique credentials generated at manufacture, provisioning or first boot.
Enforce a secure initial set-up	Require a credential change, key provisioning or account creation before allowing privileged or sensitive access.
Restrict initial permissions	Grant the minimum permissions required for initial operation. Avoid granting full administrative access by default.
Protect initial access paths	Ensure that first-boot, onboarding and recovery interfaces are authenticated and not unnecessarily exposed.

Minimum evidence

No default credentials shipped: build configuration or documentation confirms that no shared or hard-coded credentials exist.
Unique credentials enforced: provisioning records, configuration or device inventory shows per-device or per-instance credentials.
Secure set-up required: configuration or test evidence shows credential change or secure set-up is mandatory before privileged or sensitive access.
Initial permissions restricted: access model or configuration shows limited permissions at first use.
Initial access paths controlled: configuration or test evidence shows that onboarding and recovery interfaces are protected.

Release gate

No shared or default credentials present in production builds
Unique credentials generated for each device or instance
Secure set-up enforced before privileged or sensitive access
Initial permissions are restrictive by default
Initial access and onboarding paths are protected and reviewed

4.17 Secure communication by default

Principle (secure by default)	Enforce secure communication from the start. All external communications must be encrypted and authenticated by default, with no support for insecure or plain-text protocols for convenience.
Objective	Protect data in transit and prevent interception, tampering or impersonation by ensuring that communications are always secure, without relying on user configuration or later hardening.

Checklist

Protect external communications by default	Require encrypted communication for all external interfaces from first use. Where data or commands pass through intermediaries, assess whether transport protection alone is sufficient or whether additional end-to-end authenticity, integrity and freshness controls are required.
Disable insecure and plain-text protocols	Do not allow unencrypted or weak protocols (e.g. HTTP or Telnet) to be used by default or even as fallbacks.
Authenticate communicating endpoints	Ensure that external endpoints authenticate each other where appropriate, for example for device-to-cloud, service-to-service and administrative access.
Enforce secure protocol versions and configurations	Use modern, secure protocol versions and configurations by default. Explicitly disable weak ciphers, legacy versions and insecure negotiation modes.
Fail securely on connection errors	Ensure that communication failures result in denied connections rather than downgrading to insecure protocols or configurations.
Plan for cryptographic change	Design cryptographic mechanisms so that algorithms, keys, certificates and trust anchors can be replaced or migrated without substantially redesigning the product, where feasible. Assess whether the product’s support lifetime, data confidentiality requirements and deployment constraints require preparation for migration to post-quantum cryptography.

Minimum evidence

Secure protocols enforced by default: configuration or test evidence shows that encrypted and authenticated communication is required from first connection.
Insecure protocols disabled: configuration confirms that plain-text or legacy protocols are not enabled or available.
Endpoint authentication in place: configuration or test evidence shows that mutual or appropriate endpoint authentication takes place for external communications.
Strong protocol configuration applied: configuration shows that only approved protocol versions and cryptographic settings are enabled.
No insecure fallback: test evidence shows that connection attempts fail securely rather than downgrading security.
Cryptographic migration note: identification of critical cryptographic mechanisms and how algorithms, keys, certificates and trust anchors are to be updated or replaced.

Release gate

External communications are encrypted and authenticated from first connection
Insecure or plain-text protocols are disabled and unavailable
Only approved secure protocol versions and configurations are enabled
Endpoint authentication enforced where required
Connection failures do not result in insecure fallback
Cryptographic mechanisms can be replaced or migrated where required by the product’s risk assessment and support lifetime.

4.18 Unique device identity and secrets by default

Principle (secure by default)	Ship each product instance with a unique cryptographic identity and secrets by default if it uses any private/secret value. Do not use shared credentials, keys or certificates across devices or installations.
Objective	Prevent large-scale compromise by ensuring that a breach of one device or a leaked secret cannot be reused to attack other devices, customers or the wider installed base.

Checklist

Generate unique identities per device or instance	Assign a unique device identity (e.g. key pair or certificate) to every device or installation.
Eliminate shared or hard-coded secrets	Do not use shared credentials, default keys or embedded secrets across products.
Protect secrets against extraction	Store device identities and per-device secrets using platform-appropriate controls that protect against extraction, tampering or unauthorised replacement (e.g. secure storage, hardware-backed protection or restricted access).
Use unique secrets for security-critical functions	Ensure that security-critical functions like authentication, secure communications and update verification rely on per-device secrets, not shared material.
Support revocation and replacement	Ensure that device identities and secrets can be revoked and rotated if compromise is suspected.

Minimum evidence

Unique device identities issued: device inventory or provisioning records show a unique identity (e.g. key pair or certificate) for each device or instance.
No shared secrets present: build artefacts or configuration confirms that no shared credentials or hard-coded secrets exist.
Secrets protected at rest: documentation or configuration shows that secrets are stored using appropriate protection mechanisms.
Security functions use unique secrets: configuration or design notes show that authentication, communication and update processes rely on per-device secrets.
Revocation supported: documentation or configuration shows that device identities or secrets can be revoked or replaced.

Release gate

Unique cryptographic identity generated for each device or instance
No shared or default secrets present in production builds
Secrets are protected against extraction
Security-critical functions use per-device secrets
Identity and secret revocation or replacement is supported

4.19 Mandatory security onboarding

Principle (secure by default)	Require critical security controls to be configured during initial set-up. Do not allow products to enter an operational state until essential security steps are completed.
Objective	Ensure that systems start in a secure state by preventing or limiting use before baseline security controls, such as strong authentication or encryption, are configured.

Checklist

Identify mandatory security steps	Define the minimum security controls required before the product can be used (e.g. MFA, encryption keys, admin account set-up).
Enforce security set-up during first use	Integrate mandatory security steps into the initial set-up or onboarding flow. Do not allow users to skip or defer required security configuration.
Block operation until onboarding is complete	Prevent normal operation, privileged actions and external connectivity until mandatory security steps are completed.
Provide clear, guided configuration	Guide users through security set-up with clear instructions and sensible defaults. Avoid requiring expert knowledge to complete onboarding securely.
Re-trigger onboarding when security is incomplete	Re-enforce onboarding if critical security settings are removed, reset or left unconfigured.

Minimum evidence

Mandatory security steps defined: documentation identifies which security controls must be completed during onboarding.
Onboarding enforces a security set-up: configuration, screenshots or test evidence shows that critical security steps cannot be skipped.
Operation blocked pre-onboarding: configuration, screenshots or test evidence shows that the product cannot enter normal operation before onboarding is complete.
Guided set-up is provided: screenshots, configuration flows or documentation shows that clear user guidance is provided on security set-up.
Onboarding is re-enforced on incomplete security configuration: configuration, screenshots or test evidence shows that onboarding is re-triggered if required security settings are missing.

Release gate

Mandatory security steps are defined and enforced during initial set-up
Users cannot bypass or skip critical security configuration
Product cannot enter normal operation before onboarding completion
Security onboarding provides clear guidance and secure defaults
Onboarding is re-enforced if critical security settings are removed

4.20 Automated maintenance and updates

Principle (secure by default)	Manufacturers should provide secure update mechanisms that minimise user and operational effort. Security updates should be enabled by default, while allowing authorised users or operators to approve or schedule installation where the deployment requires controlled updates.
Objective	Ensure that vulnerabilities are addressed quickly and the device is left vulnerable for as little time as possible.

Checklist

Enable managed security updates by default	Enable security updates by default, ensuring that the product automatically checks for updates, informs the user and supports timely installation, with escalation where updates are repeatedly deferred. Where unattended installation could affect safety, availability or operational continuity, support staged rollout, maintenance windows and authorised operator approval.
Separate security updates from feature changes	Ensure that critical security updates can be delivered independently of optional feature/functional updates.
Verify the authenticity and integrity of updates	Ensure that updates are cryptographically verified before installation.
Apply updates safely	Design updates to minimise disruption and avoid leaving the system in an insecure or unusable state if the update fails. Support staged rollout, maintenance windows, operator approval and rollback where required by safety, availability or operational-continuity considerations.
Inform users of update activity	Notify users when security updates are applied or when action is required, without requiring them to manage the update process manually.

Minimum evidence

Automatic updates enabled: default configuration shows that security updates are enabled out of the box.
Security updates decoupled: configuration or release notes show that security fixes can be delivered independently of optional feature/functional updates.
Update verification enforced: configuration or design notes show that updates are authenticated and integrity-checked.
Safe update mechanism in place: documentation or test evidence shows that updates can be applied without significantly disrupting basic operation.
Update strategy: documentation or test evidence shows that the update process supports controlled approval, staging and rollback where required by the deployment context.
User notification supported: logs, UI messages or documentation shows that users are informed of update activity or status.

Release gate

Security update functionality is enabled by default, with an installation approach appropriate to the product’s deployment context
Security updates can be delivered independently of features
Updates are cryptographically verified before installation
Failed updates do not leave the system insecure or unusable
Users are informed of update status without manual intervention

4.21 Transparent security posture

Principle (secure by default)	Make the system’s security posture visible and understandable. Clearly inform users when security protections are weakened and provide a simple path to return to a secure baseline.
Objective	Reduce risk arising from accidental or uninformed misconfiguration by ensuring that users understand the security state of the system and can easily correct insecure settings.

Checklist

Define security states and baseline	Define the secure baseline and any degraded or unsupported security states. Document which configurations cause a transition between states.
Expose current security status	Indicate clearly whether the system is operating in a secure or degraded security state.
Warn on changes that reduce security	Show clear warnings when users disable security features or apply configurations that increase risk.
Explain impact in plain language	Explain to the user the security implications of a change in non-technical terms.
Provide a simple path to recovery	Offer the user a simple interaction path to return to the secure baseline.

Minimum evidence

Security states defined: documentation identifies the secure baseline and degraded or insecure states, including the configuration changes that trigger such states.
Security status visible: screenshot, CLI output or documentation clearly shows the current security state.
Warnings triggered on risk increase: screenshots, prompts or test evidence shows warnings when users apply security-reducing changes.
Impact explained clearly: warning messages, screenshots or documentation demonstrates that security implications are described in plain, non-technical language.
Baseline restore available: screenshots, commands or configuration shows a simple action exists to return to the secure baseline.

Release gate

Secure baseline and degraded security states are defined and documented
Current security state is clearly visible to the user
Users are warned when security protections are reduced
Security impact is explained in clear, non-technical language
A simple action can be taken to restore the secure baseline

4.22 Secure recovery and ownership life cycle

Principle (secure by default)	Provide secure, guided recovery and ownership transfer mechanisms by default. Recovery, reset and transfer processes must be easy for users, operators and administrators to follow, while remaining resistant to abuse, account takeover and social engineering.
Objective	To enable users and administrators to recover access, reset systems or transfer ownership safely.

Checklist

Define supported recovery and transfer actions	Identify supported recovery actions such as credential reset, account recovery, secure factory reset and ownership transfer, clearly defining who is allowed to initiate each action and under what conditions
Verify identity before recovery or transfer	Require strong identity verification before allowing recovery, reset or ownership transfer actions.
Protect recovery paths from abuse	Ensure that recovery mechanisms cannot be used to bypass normal authentication or authorisation controls. Apply monitoring and rate limiting to recovery and reset workflows.
Ensure secure reset and ownership transfer	Ensure that factory reset and ownership transfer fully remove previous user access, credentials and secrets.
Provide guided, secure workflows	Offer clear recovery and transfer processes that reduce user error

Minimum evidence

Recovery and transfer actions are defined: documentation identifies supported recovery, reset and ownership transfer processes.
Strong verification is enforced: configuration or test evidence shows that recovery and transfer actions require a verified identity.
Abuse protections are applied: configuration, logs or test evidence shows that rate limiting and monitoring of recovery workflows are in place.
Secure reset and transfer is verified: test evidence confirms that factory reset and ownership transfer remove prior credentials and access.
Guided workflows are available: screenshots, CLI commands or documentation demonstrates that recovery and transfer processes are guided.

Release gate

Supported recovery and ownership transfer actions are defined
Recovery and transfer actions require strong identity verification
Recovery mechanisms cannot bypass normal access controls
Factory reset and ownership transfer fully remove prior access
Clear guidance is provided on recovery and transfer workflows

4.23 Progressive adoption of the playbooks

This section provides an illustrative progressive adoption sequence, showing how the playbooks can be adopted and applied over time. The example begins with activities that provide context and prioritisation, followed by a foundational engineering baseline and then a broader and more mature implementation of the principles. Progressive adoption here refers to how organisations build and strengthen their security practices over time. It does not suggest delaying applicable requirements or controls, particularly those arising from legal obligations, including under the CRA. This guidance is without prejudice to such obligations, which take precedence.

1.1 Nuorodos

1.2 Nustatyti reikalavimai

1.3 Susiję teisės aktai

2. Nustatyti reikalavimai

Reikalavimai
Šaltinis	Reikalavimas

3. Susiję teisės aktai

Teisės aktai
Šaltinis	Reguliavimas

ENISA -