A product's security architecture is its most consequential design decision and its hardest to change. Defence-in-depth layering, zone and conduit models, privilege separation, fail-secure modes, and compartmentalisation to contain compromise are all structural properties that must be committed to early. Attack surface reduction, minimising exposed interfaces, protocols, and services, is an integral part of good architecture rather than a separate activity. Recovery and rollback mechanisms (factory reset, safe-mode boot, firmware rollback to a verified version) are equally architectural: they determine whether a compromised product can be restored without physical intervention.

The challenge is adapting general patterns to the constraints of embedded, resource-limited, and safety-critical products, where memory, processing power, and certification requirements restrict design freedom. Products deployed across fleets of thousands of units need architecture that scales: patterns that work on a prototype must also work at production volumes with diverse network environments and integration contexts.

Every connected product depends on cryptography for confidentiality, integrity, authentication, and non-repudiation. The choices that govern whether that protection holds (e.g. algorithm selection, protocol-level integration, key hierarchy design) are made during product design and are difficult to change after manufacturing. A particularly consequential aspect is key ownership: as a product moves from manufacturer to system integrator to end customer, it must be unambiguous who holds which keys and under what conditions ownership transfers. Equally, the full key lifecycle (generation, secure storage, rotation, revocation, and recovery) must be planned for product lifetimes that can span decades and fleets that number in the thousands. Weaknesses here, such as hardcoded keys, unclear ownership at handover points, or missing integrity checks, are among the most persistent sources of product security failures across industries.

The regulatory and technical landscape adds urgency. The Cyber Resilience Act requires manufacturers to apply cryptography appropriately and maintain it over the support period. Post-quantum cryptography migration means products shipping today need crypto-agility: the architectural capacity to replace cryptographic algorithms without hardware changes. Hybrid classical/post-quantum schemes must be selected and validated. Cryptographic mechanisms also play a direct role in protecting manufacturers and supplier intellectual property (e.g. encrypted firmware, obfuscation, and secure IP embedding) making this topic relevant well beyond the traditional confidentiality and integrity concerns.

Connected products depend on protocols for every external interaction: standard protocols (TLS, MQTT, DTLS), industrial protocols (OPC-UA, Modbus, Profinet, EtherCAT), and authentication protocols (mTLS, OAuth 2.0, OIDC, FIDO, X.509). The protocol chosen, and how it is configured, directly determines the strength of authentication, the confidentiality of data in transit, and the integrity of commands received. Protocol selection affects not just security but also interoperability and operational complexity: more secure configurations may break integration with legacy systems.

Industrial protocols present a particular challenge. Many were designed for isolated networks and lack built-in security: Modbus has no authentication, BACnet has minimal encryption support, and even OPC-UA implementations vary widely in which security profiles they actually enforce. Securing these protocols without breaking interoperability or real-time performance constraints is an active area of innovation. The sub-elements include protocol selection and configuration hardening, TLS/DTLS profile management, industrial protocol security (wrapping or upgrading insecure legacy protocols), authentication protocol integration for constrained devices, and API security for product management interfaces.

Runtime hardening encompasses engineering decisions baked into the build: secure kernel configuration, filesystem permissions, memory protections (ASLR, stack canaries, NX), service minimisation, and removal of unnecessary debug tooling. Secure defaults determine the attack surface at first power-on: unique per-device credentials instead of default passwords, closed ports until explicitly configured, disabled unnecessary services, and least-privilege access policies. The practical reality is that the security posture at first power-on is often the security posture for the product's entire lifetime, because most customers never change defaults.

The CRA mandates secure-by-default configurations, making hardening a compliance concern alongside a design discipline. The sub-elements include OS and kernel hardening for embedded Linux and RTOS platforms, memory protection deployment on resource-constrained hardware, service minimisation and attack surface reduction at build time, default credential elimination (unique per-device credentials provisioned during manufacturing), and production-disabling of debug interfaces (JTAG, UART, diagnostic modes).

Products deployed in physically accessible environments face adversaries who can touch, open, and instrument the hardware. Anti-tamper design principles, tamper detection and response mechanisms (such as zeroisation of secrets on tamper detection), physical access controls, and countermeasures against side-channel attacks are all part of this topic. Side-channel resistance, specifically, includes constant-time cryptographic implementations, power analysis masking, electromagnetic shielding, and fault injection countermeasures. For products in unattended locations such as energy infrastructure, field equipment, and building systems, physical security is the first line of defence rather than an optional hardening layer.

Physical access control mechanisms (secure boot tied to hardware identity, anti-cloning measures) round out the design space.

Products in industrial, medical, and automotive contexts often have constrained interfaces: small displays, physical controls, limited input methods. Traditional security UX patterns like complex passwords, multi-step configuration wizards, and certificate management workflows are impractical or even dangerous in contexts where every second matters (a radiographer authenticating per patient scan, an operator responding to a process alarm). The product's interface must make the secure option obvious and the insecure option difficult, because the configuration set at installation is likely the configuration that persists for years.

The sub-elements include authentication UX for constrained product interfaces, secure-by-default interaction patterns that minimise misconfiguration risk, role-based access through both physical and digital means, multi-user access management for products shared across roles (installer, operator, service engineer, administrator), and human factors of security in safety-critical operational contexts.

Products generate data that may belong to different parties simultaneously: operational telemetry to the manufacturer, process data to the customer, usage data to the end user. Privacy architecture establishes who owns what, how data is categorised by sensitivity, and what technical mechanisms enforce protection by construction rather than by policy. This includes privacy-enhancing technologies (differential privacy, homomorphic encryption, federated learning, secure multi-party computation) and active transparency functions that give customers visibility and control over their data, including dashboards, export capabilities, processing opt-outs, and deletion capabilities.

GDPR applies wherever products process personal data, and sector-specific data rules add further obligations. But beyond regulatory compliance, data transparency is becoming a competitive differentiator: customers increasingly evaluate products partly on how clearly they can see and control what data is collected, where it is processed, and with whom it is shared. The sub-elements include data classification and ownership models, access control and consent management for product-generated data, data integrity and provenance tracking, privacy-enhancing technologies for edge processing, and customer-facing data transparency and control functions.

AI features in products, such as machine vision, predictive maintenance, anomaly detection, and natural language interfaces, introduce security concerns distinct from traditional software: adversarial inputs causing misclassification, model drift degrading performance over time, lack of explainability undermining trust, and failure modes that were not anticipated in safety analysis. Securing AI integration means ensuring that the AI components behave predictably even when deliberately probed or manipulated, and that their outputs can be understood and overridden when needed.

The EU AI Act classifies many product-embedded AI systems as high-risk, adding conformity assessment obligations that intersect with CRA requirements. The rules for high-risk AI systems embedded in regulated products have an extended transition period until August 2027, aligning with the CRA's full application date. The sub-elements include adversarial robustness testing for product-embedded models, input validation and output bounding for AI features, explainability mechanisms for regulatory and operational purposes, AI-specific monitoring (model drift, performance degradation, distribution shift), and safety-AI interaction design (ensuring AI features cannot override safety-critical constraints).

TEEs, secure elements, HSMs, and TPMs provide tamper-resistant key storage, hardware-backed attestation, secure boot anchoring, and isolated execution environments. Confidential computing enables products to process sensitive data without exposing it to the host system, the manufacturer, or other tenants. For products that process customer data on manufacturer-controlled platforms, or that operate in environments where the manufacturer cannot trust the host, confidential computing provides guarantees that contractual promises alone cannot deliver.

The selection and integration of trusted hardware is a design-time decision with long-term consequences: it determines the ceiling of security assurance a product can achieve and is impractical to retrofit. The sub-elements include TEE architecture selection and integration (ARM TrustZone, Intel TDX, RISC-V Keystone), secure element and HSM integration for key storage and cryptographic operations, hardware-backed remote attestation (proving platform state to a verifier), confidential computing as an IP protection mechanism (running supplier algorithms inside TEEs so the manufacturer cannot extract proprietary logic), and TPM-based measured boot for deployment integrity verification.

A product that cannot reliably prove who it is cannot participate in any trust relationship. Secure updates, fleet management, remote access, and customer operations all depend on identity. This topic spans initial identity models (X.509 certificates, decentralised identifiers, manufacturer-assigned serials), factory-floor provisioning (key injection, zero-touch provisioning, first-boot trust establishment), runtime attestation (secure boot chains, measured boot, remote attestation proving platform state), and lifecycle management (rotation, revocation, re-provisioning, decommissioning).

The choice of identity model has deep implications for interoperability, scalability, and cost. Certificate-based identity requires PKI infrastructure for issuance, renewal, and revocation across potentially millions of devices over decades. Zero-touch provisioning must work across manufacturing partners and contract manufacturers without exposing provisioning secrets. The sub-elements include identity model selection and provisioning infrastructure design, factory-floor key injection and secure manufacturing integration, certificate lifecycle management at fleet scale (automated renewal, revocation, CRL/OCSP), device identity for multi-stakeholder environments (manufacturer, integrator, customer each with their own identity requirements), and decommissioning identity cleanup (certificate revocation, key zeroisation, identity de-registration).

Products deployed at scale across dispersed locations cannot rely on centralised security teams for real-time response. The autonomous frontier of product security is products that protect themselves: using behavioural analysis, anomaly detection via ML models, and automated response actions faster than any human operator. The critical constraint is that autonomous responses must respect safety boundaries and operational requirements. In a safety-critical product, an autonomous security action that disrupts the primary function (shutting down a medical device, disabling a vehicle control system) can cause more harm than the attack it is responding to.

The sub-elements include on-device anomaly detection using ML models (behavioural baselines, network traffic analysis, process monitoring), automated response actions (session termination, feature isolation, fallback to safe mode), safety-aware response design (ensuring autonomous security actions cannot violate safety invariants), validation and testing frameworks for autonomous security behaviours, and the feedback loop between autonomous detection and fleet-level threat intelligence. This is an emerging area with no widely accepted framework for testing and certifying autonomous security behaviour.

Security requirements engineering is the discipline of turning security intent into engineering-ready obligations: what the product must protect, what it must resist, and what it must prove. It focuses on translating high-level security goals, regulatory obligations, and risk assumptions into concrete, verifiable requirements that can guide design and development. It includes eliciting requirements from sources such as legislation (e.g. CRA, MDR, UN R155 and R156), standards (e.g. ISO/SAE 21434), threat analyses, and stakeholder expectations, then structuring and documenting them in a way that is actionable for engineers. In practice this means expressing security not as a vague goal (“be secure”), but as specific constraints and behaviours (e.g., authenticated update installation) that can be designed and implemented. A key characteristic is bidirectional traceability: requirements must link forward to design elements, tests, and evidence, and backward to their originating risks or obligations.

Security requirements engineering is critical because gaps or ambiguities at this stage propagate further in the product development process and are expensive or impossible to fix later. Without clear requirements, security becomes implicit, inconsistently interpreted, or entirely overlooked. Misuse and abuse cases make attacker and operator failure modes explicit, so teams design for how the product will be broken rather than only for how it should be used. Requirement taxonomies (confidentiality, integrity, availability, safety, privacy) prevent systematic blind spots by forcing coverage across different harm types. Requirement‑to‑test traceability (often via trace matrices and requirements tooling) ensures each requirement is validated and evidenced, closing the loop between intent, implementation, and compliance proof instead of leaving security as an assumption.

This subcluster encompasses systematic methods for reasoning about adversaries, assets, and attack paths in the context of the product’s architecture and operating environment. Techniques such as STRIDE, LINDDUN, attack trees, MAL or domain-specific methods are used to explore how the product could be compromised, considering architecture, data flows, and operational context. Threat modelling is best performed iteratively, evolving as the product design matures and as deployment contexts change.

Threat modelling is essential because it provides the rationale for security requirements, architecture, controls and test plans, ensuring that defences are risk-driven rather than checklist-based. It helps development teams focus effort on realistic and high-impact threats, reducing both overengineering and blind spots. Asset inventories clarify what is valuable (keys, safety functions, firmware integrity, sensitive data) so protection effort is correctly concentrated. Attacker models set realistic assumptions about capabilities (remote vs. physical access, insider vs. outsider), which prevents both overengineering and dangerous underestimation. Trust boundary identification reveals privilege transitions and implicit dependencies—common places where vulnerabilities hide—while threat prioritisation and documented assumptions/accepted risks create an auditable rationale for trade-offs and a clear backlog for mitigation.

This subcluster focuses on embedding test hooks, diagnostics, and controlled fault-injection capabilities into the product so that security claims can be validated during development and manufacturing. It includes designing for observability of security-relevant behaviour (e.g. boot mode, key status, privilege level) without adding new attack vectors for the product in production.

Security controls that cannot be tested are effectively assumptions, and untestable security often hides latent vulnerabilities. Good testability design enables earlier detection of security defects and stronger evidence for compliance and assurance. Fault injection points and stress hooks help uncover edge cases (glitches, malformed inputs, timing races) that frequently produce exploitable weaknesses, especially in embedded systems. Observable security states and security event logging provide evidence for assurance and accelerate debugging of security defects. Secure production-disable mechanisms and locked-down debug/test interfaces are equally critical: they preserve the benefits of test access in development while preventing those same interfaces from becoming post-deployment backdoors.

This subcluster covers the engineering discipline required to build secure products, including coding standards, peer review processes, and tool-supported workflow controls. It spans both human practices (training, review culture, responsibility assignment) and technical enablers such as static analysis, linters, and secrets management. Increasingly, it also includes AI-assisted development and review, which introduces new opportunities and risks.

Most product vulnerabilities arise from implementation errors rather than fundamental design flaws, making secure development practices a primary line of defence. Consistent practices reduce variability in code quality and help scale security across teams and suppliers. Coding standards reduce recurring classes of bugs (memory safety errors, injection flaws, insecure randomness) by making safe patterns the default. Peer review and “golden paths” in CI/CD catch risky changes early and enforce consistent quality across teams, including suppliers. Automated linting and policy checks prevent drift (e.g., reintroducing banned functions, weakening crypto settings), while robust credential management avoids some common product failures: secrets committed to repositories or shared across devices.

This subcluster encompasses a range of testing techniques applied at different stages of development. These include static and dynamic analysis, software composition analysis, fuzzing, penetration testing, and firmware or binary inspection. Testing may target source code, compiled artifacts, runtime behaviour, or deployed systems, depending on the lifecycle phase and threat model.

Security testing is crucial because it exposes concrete, exploitable weaknesses rather than theoretical risks. It provides feedback on the effectiveness of requirements, design decisions, and coding practices, and generates evidence needed for certification and regulatory compliance. SAST and white-box analysis help catch implementation flaws before they ship, while SCA exposes supply-chain risk by flagging vulnerable third-party components that quietly dominate the attack surface. Dynamic analysis and firmware scanning reveal misconfigurations and insecure services that are invisible in code review. Fuzzing and symbolic execution excel at uncovering rare edge cases that lead to memory corruption or logic bypass, and penetration testing validates exploitability end-to-end, ensuring that individual findings are interpreted in system context and prioritised by real impact.

This subcluster includes techniques such as model checking, theorem proving, abstract interpretation, and protocol verification to reason about system behaviour exhaustively. Rather than sampling possible executions, formal methods aim to demonstrate that entire classes of errors or attacks are impossible under stated assumptions. They are most often applied to high-assurance components such as cryptographic protocols, boot chains, or safety-critical security functions.

Formal verification is important for product security because some classes of vulnerabilities are extremely subtle, safety-critical, or costly to discover post-deployment. While resource-intensive, formal methods can provide a level of assurance unattainable by testing alone. Protocol verification can prevent systemic design errors that would compromise every device in a fleet or interfaces with external parties. Abstract interpretation and model checking can prove absence of particular bug classes (or bound behaviours) across all paths. Proof artifacts also strengthen assurance cases and compliance evidence, but only if assumptions are clearly documented and the verified component is integrated carefully, making “verified-to-system” integration a critical sub-element for maintaining the proven guarantees.

Field-to-engineering feedback loops are the mechanisms that translate what happens to products in the real world into concrete engineering improvements. It focuses on capturing security-relevant information from deployed products—such as vulnerability disclosures, incident data, telemetry, and misuse patterns, and then convert them into updates to requirements, threat models, tests, and roadmap priorities. This requires both technical infrastructure and organisational processes.

Product security is dynamic: attackers adapt, usage changes, and new dependencies are introduced over time. Feedback loops are therefore essential to prevent products from stagnating at their initial security level. PSIRT integration and structured triage ensure externally reported vulnerabilities are handled consistently and that fixes are prioritised. Telemetry and field intelligence analysis reveal weak signals like recurring authentication failures, abnormal update behaviour, unexpected network services—that often indicate emerging attacks or misconfiguration at scale. Backlog linkage and explicit updates to threat models and test cases close the loop, preventing the same vulnerability class from reappearing and turning incidents into durable improvements rather than one-off patches.

This subcluster covers the technologies that let product builders verify that the input to the build process is exactly what ends up in the final product. The build must always be able to answer — and ideally prove — what was built, who built it, and in what environment. Build processes typically have multiple stages, and addressing these questions at each stage builds confidence that the overall process was completed without tampering.

Product build integrity has additional facets on top of generic software build integrity. Because products typically include hardware, extra care must be taken that the built software is also what runs on the supplied hardware, and that no additional components are injected at any stage.

This subcluster covers the generation of SBOMs across different environments, and pushes the question of what should be in an SBOM beyond the established baseline. It also interacts with other kinds of BOMs relevant to products, such as hardware and AI-model BOMs. Generating an SBOM that accurately represents the software at hand remains challenging: SBOM tooling is much newer than the rest of the software development pipeline, and SBOM generation is not yet routinely baked into build processes.

SBOMs are a mandatory part of modern supply-chain security under the CRA. This base of truth about the supply chain is pivotal for establishing product trust, and for interfacing with BOMs covering other aspects of the supply chain such as hardware and AI models.

Setting up a solid supply chain and build process — with signatures, provenance attestations, and SBOMs — is only one step in product supply-chain security. Verifying the eventual result, potentially also on products already in the field, requires integration of supply-chain technologies and sensible checks against expectations. This subcluster covers the tools to digest and verify the information produced by build integrity and SBOM-generation processes, and to use that information in novel ways such as structured vulnerability assessment and disclosure.

Once a product is deployed, it leaves the direct view of the supplier, and the hardware and software within it may be modified, tampered with, or degraded over time. Verifying the provenance and contents of a deployed product, both at acceptance and periodically thereafter, is a powerful tool for maintaining confidence and detecting compromise.

This subcluster covers the specifics of the AI development pipeline, including protection of model weights at rest and in use, integrity of the training and fine-tuning pipeline, and the security of base models and datasets sourced from third parties.

AI models are increasingly central to products, but these new capabilities come with novel risks. Malicious inclusions reaching the product via the model — through data poisoning, or inherited from a base model or third-party dataset — are much harder to detect than equivalent threats in classical software. Protection of the model embedded in the product also matters commercially: a source-code leak is typically less damaging than leaking model weights that constitute the product's unique selling point.

Beyond the technical aspects of the supply chain, which can be addressed through technical measures, supplier governance covers the organisations behind the components included in the product: commercial vendors, contract manufacturers, open-source projects, and the people who maintain them.

Even a technically perfect supply chain depends on the trustworthiness of the parties that supply each component. Suppliers may go out of business, change ownership, get compromised, or shift their security posture; open-source projects may be taken over by a single new maintainer who later acts maliciously. Supplier governance is the discipline of maintaining ongoing visibility into and influence over these parties: vetting and onboarding processes for commercial suppliers, contractual security obligations and right-to-audit clauses, monitoring of maintainer changes and ownership transfers for critical open-source dependencies, and structured handling of supplier security incidents that may cascade into product impact.

Connected products entering the EU market increasingly face multiple concurrent regulatory obligations. The CRA imposes horizontal cybersecurity requirements on all products with digital elements, while sector-specific regulations layer additional demands: MDR and IVDR for medical devices, UN R155 and R156 for automotive, RED for radio equipment, SEMI for semiconductor manufacturing equipment. The EU AI Act adds conformity assessment requirements for products with embedded AI classified as high-risk. Data protection obligations under GDPR apply wherever products process personal data. Each regulation imposes its own technical and procedural requirements, and they overlap, interact, and occasionally conflict.

The practical challenge is not understanding any single regulation in isolation but building a compliance strategy that scales across a product portfolio. A manufacturer shipping a connected medical imaging system must simultaneously satisfy CRA essential requirements, MDR cybersecurity expectations, EU AI Act obligations for any embedded AI models, and GDPR requirements for patient data processing. Doing this through four separate compliance tracks is prohibitively expensive. The sub-elements of this topic include multi-regulation gap analysis, compliance architecture across horizontal and vertical regulations, technical file structuring that satisfies multiple frameworks simultaneously, and conformity assessment pathway selection (self-assessment vs. third-party vs. EU cybersecurity certification).

The standards underpinning product security compliance are being written now. IEC 62443 remains the de facto horizontal product security standard, but CEN-CENELEC JTC13 is developing a new generation of harmonised standards (the EN 40000 series) specifically for CRA compliance. ETSI contributes vertical standards for specific product categories. ISO 27001, ISO/SAE 21434, ETSI EN 303 645, and sector-specific standards from SEMI and TISAX add further layers. Standards provide the technical translation of regulatory intent into implementable requirements, and they standardise vocabulary, expectations, and evidence formats across the supply chain.

Engagement gives manufacturers influence over the rules they will be held to, and early visibility into requirements that may take years to finalise. For any single company, the bandwidth required to participate in all relevant working groups is rarely available. The sub-elements include tracking and participating in horizontal standardisation (JTC13 WG9 for CRA), vertical standardisation (product-specific working groups), international standardisation (IEC, ISO), and industry consortium standards (SEMI, TISAX). Understanding how standards interact, where they conflict, and where gaps remain is itself a knowledge-intensive activity that benefits from collective effort.

Having the right technical capabilities is necessary but insufficient if the organisation cannot consistently apply them. Security governance addresses how security decisions are made, who has authority at each lifecycle phase, and how security is embedded in engineering teams rather than bolted on as a separate function. This includes lifecycle gates and reviews (design reviews, release approvals, change control), PSIRT design and operation, security champion models that distribute expertise into product teams, and cross-functional alignment when multiple business units, product lines, or engineering cultures must operate under a shared security policy.

Equally important is how exceptions are handled. No product ships with zero known issues; the question is whether deviations from security requirements are formally documented, risk-accepted with compensating controls, and tracked to remediation deadlines, or whether they are informally ignored. The sub-elements include organisational reporting structures for product security, security training and skills development programmes, structured risk acceptance and exception management, and governance mechanisms for aligning product security across mergers, acquisitions, and joint ventures.

Knowing where you stand is a prerequisite for knowing where to invest. Maturity models like BSIMM, OWASP SAMM, and IEC 62443 capability/maturity levels provide structured ways to assess organisational product security practices, benchmark against industry peers, and track progress over time. They translate the abstract question "how good is our product security?" into assessable activities and observable outcomes. Product-specific KPIs complement organisational maturity: mean time to patch, vulnerability backlog age, percentage of fleet on current firmware, security test coverage, and incident response times measure operational performance rather than process maturity.

The risk is that measurement becomes a bureaucratic exercise that optimises for scores rather than outcomes. Metrics that reward closing low-severity findings quickly while ignoring systemic architectural weaknesses drive the wrong behaviour. The sub-elements include framework selection and adaptation (choosing which maturity model fits the organisation's context), metric design (selecting KPIs that correlate with actual risk reduction), benchmarking (comparing against peers while accounting for different product domains and risk profiles), and maturity roadmap development (turning assessment results into prioritised improvement plans with realistic timelines).

Regulators and customers demand structured proof of security practices: technical files, risk assessments, test reports, SBOM snapshots, vulnerability handling records, and code review logs. Generating this documentation manually is slow, error-prone, and scales poorly across product portfolios with multiple regulatory frameworks. Evidence automation treats compliance documentation as a build artifact, generated alongside the product itself rather than assembled retrospectively by a separate compliance team.

The CRA's expectation of machine-readable technical files makes automation structurally necessary, not merely efficient. The sub-elements include policy-as-code (encoding security policies as executable rules checked in CI/CD), compliance-as-code (mapping engineering artifacts to specific regulatory requirements automatically), automated technical file generation (assembling CRA/MDR/RED documentation from pipeline outputs), and audit trail automation (creating tamper-evident records of security decisions, reviews, and approvals). This is where the most significant technical innovation opportunity exists within the governance cluster: the gap between what regulators expect and what current tooling delivers is large.

When a security researcher, customer, or internal team discovers a vulnerability in a deployed product, the manufacturer needs a structured, trusted process for handling it. This includes PSIRT intake processes (secure reporting channels, acknowledgement timelines), triage and prioritisation (assessing severity and exploitability in the product's specific deployment context), coordinated disclosure (agreeing timelines with researchers, managing pre-notification to affected customers), and advisory publication in machine-readable formats. The CRA mandates that manufacturers operate a vulnerability handling process and report actively exploited vulnerabilities to ENISA within 24 hours of awareness, with full notification within 72 hours.

The sub-elements include PSIRT intake and case management, researcher relations programmes (including bug bounty and safe harbour policies), VEX publication (confirming which product versions are affected or unaffected by a given CVE), CSAF advisory distribution, and integration with the EU's vulnerability reporting infrastructure. The tooling ecosystem for coordinated vulnerability disclosure is an active area of innovation with significant room for improvement: many manufacturers still manage disclosure through email and spreadsheets, which cannot meet CRA reporting timelines at scale.

This subcluster refers to the end-to-end process by which manufacturers deliver firmware, patches, or software upgrades to deployed devices while ensuring that only authentic, untampered code is installed. A secure Over-The-Air (OTA) update mechanism protects software integrity and authenticity and is the only practical way to fix vulnerabilities after a product ships. The process includes secure build and signing, trusted distribution, protected download, on-device signature verification, safe installation with rollback support, and post-update validation.

Without a reliable update path, vulnerabilities discovered after launch become permanent, and without a secure one, the update channel itself becomes a major attack vector because updates are inherently trusted. Secure OTA enables faster patching, regulatory compliance with EU CRA, ISO 21434, and IEC 62443, and allows post-launch feature expansion, but only if designed for resilience from the start.

Typical sub-elements include code signing with PKI, encrypted transport (TLS), on-device signature and integrity verification, A/B partition schemes with automatic rollback, anti-rollback protection against downgrade attacks, secure boot chaining, and fleet version monitoring.

This subcluster can be defined as the structured, ongoing discipline of tracking known and newly discovered weaknesses in a product's own code, its third-party components, and its operating environment, then deciding what to fix, when, and how. It spans the full loop from discovery through intake, triage, prioritisation, remediation, and verification, and feeds directly into the secure update (E1) pipeline once a fix is ready.

New vulnerabilities in third-party libraries, operating systems, and a manufacturer's own code surface constantly after release, and attackers routinely weaponise them within hours of public disclosure, meaning a product that is not actively monitored will drift from secure to exploitable without any change on the manufacturer's side.

Typical sub-elements include CVE and advisory monitoring, SBOM-based component tracking, coordinated vulnerability disclosure programs (VDP), bug bounties, severity scoring with CVSS and EPSS, risk-based prioritisation, and SLA-driven remediation workflows.

Incident response in a product security context covers how a manufacturer reacts when one of its products is actively exploited, misused, or implicated in a breach, whether the root cause lies in the product itself or in how it was deployed. It spans detection and triage, forensic investigation, containment through patches or mitigations, customer notification, regulatory reporting, and post-incident review to prevent recurrence.

Even the most securely designed product will eventually face an incident, and the speed and transparency of the manufacturer's response often determines whether the outcome is a contained event or a large-scale breach affecting thousands of customers. Regulations now impose strict timelines, such as the EU CRA's 24-hour early-warning rule for actively exploited vulnerabilities.

Typical sub-elements include a Product Security Incident Response Team (PSIRT), incident playbooks, forensic and telemetry collection, customer advisories and CVE publication, regulatory reporting to bodies like ENISA or CISA, and lessons-learned reviews.

End-of-life (EOL) management covers the structured process by which manufacturers and operators retire products that have reached the end of their supported life, whether by withdrawing security updates, decommissioning deployed units, or securely disposing of hardware and residual data. It spans the manufacturer's side (declaring and communicating EOL dates, issuing final updates, publishing transition guidance) and the customer side (asset inventory, secure data sanitisation, chain-of-custody tracking, certified destruction or resale).

A product at end-of-life without a plan becomes a permanent, unpatched attack surface: any vulnerability discovered after EOL will never be fixed, and attackers actively monitor EOL milestones to target legacy systems. Equally, retired hardware often still contains credentials, configuration data, and sensitive customer information that can be recovered if disposal is mishandled, turning a decommissioned device into a back door.

Typical sub-elements include clearly declared support periods, EOL announcements and migration guidance, final security patches, cryptographic erasure or physical destruction of storage, chain-of-custody documentation, and certificates of data destruction aligned with standards like NIST SP 800-88.

This subcluster refers to the process by which manufacturers gather real-world data from products already in customers' hands, turning the deployed fleet into a continuous source of insight about how products actually behave, fail, and are attacked outside controlled environments. It covers product telemetry (logs, crash data, performance metrics), usage patterns, exploitation attempts observed in the wild, abnormal behaviours, and contextual threat signals, all fed back into the manufacturer's security operations and engineering teams.

Without field intelligence, a manufacturer is effectively blind to what happens after a product ships, meaning emerging attack techniques, zero-day exploitation, and misconfigurations at customer sites can persist for months before being noticed. It closes the loop between design-time assumptions and real-world conditions, enabling faster detection of novel threats, data-driven prioritisation of patches, early warning of active exploitation, and evidence-based improvements to future product versions.

Typical sub-elements include secure telemetry pipelines, crash and exception reporting, fleet-wide anomaly detection, threat intelligence enrichment, privacy-preserving data collection, and feedback loops into vulnerability management and product engineering.

A digital twin is a high-fidelity virtual model of a physical product, system, or infrastructure, connected to its real-world counterpart through a two-way flow of real-time data so that it mirrors the actual deployed environment. In a product cybersecurity context, digital twins allow manufacturers and operators to simulate attacks, test patches, validate configuration changes, and rehearse incident response scenarios against an accurate replica of the live system, without risking downtime, safety, or data integrity on the real product.

Once a product is deployed, especially in critical environments like industrial plants, medical devices, or connected vehicles, the cost of experimenting directly on the live system is prohibitive, yet the need to validate security changes continuously has never been higher. Digital twins bridge this gap by providing a safe, production-grade sandbox for vulnerability testing, patch validation before rollout, attack path analysis, and training, shifting security operations from reactive cleanup toward proactive, evidence-based defence.

Typical sub-elements include synchronised real-time data feeds, physics-based or behavioural system models, attack simulation environments, patch pre-validation workflows, SBOM-linked component twins, and incident replay capabilities.

Remote access covers the mechanisms through which manufacturers, service providers, and authorised users reach deployed products, whether industrial controllers, medical devices, vehicles, or IoT endpoints, without being physically present. In a product cybersecurity context, it spans the infrastructure (VPNs, jump hosts, brokered gateways, cloud remote management platforms), the identity and access controls that govern who can connect, and the session-level protections that ensure every interaction with the deployed product is authorised, encrypted, auditable, and reversible.

Remote access is simultaneously one of the most valuable post-deployment capabilities, enabling faster diagnostics, predictive maintenance, and rapid patching, and one of the most dangerous attack vectors, since a compromised remote channel gives attackers the same privileged reach as a legitimate engineer. Dragos reported that over 60% of OT-related cyber incidents in 2024 involved remote access vectors, and similar patterns appear across healthcare and consumer IoT.

Typical sub-elements include multi-factor authentication, zero-trust network access (ZTNA), session recording and auditing, just-in-time access provisioning, vendor and third-party access management (VPAM), protocol-aware gateways for legacy OT systems, and network segmentation.

Security monitoring is the ongoing, real-time surveillance of deployed products for signs of active attack, unauthorised access, malicious behaviour, or policy violations, going beyond the question of "what vulnerabilities exist" to "what is actually happening right now." It spans log collection and correlation, network traffic inspection, endpoint behaviour analysis, identity and access monitoring, and threat intelligence enrichment, with the goal of shortening the window between compromise and detection, which industry data consistently places at months rather than hours.

A deployed product sits in environments the manufacturer does not fully control, facing adversaries who continuously evolve their tactics, and even a perfectly designed product can be abused, misconfigured, or targeted in ways that only become visible through behaviour rather than code. IBM's 2024 Cost of a Data Breach report found an average dwell time of 199 days before detection and 73 more days to contain, meaning monitoring is often the difference between a contained incident and a catastrophic breach.

Typical sub-elements include log aggregation and SIEM correlation, intrusion detection and prevention (IDS/IPS), endpoint and extended detection and response (EDR/XDR), user and entity behaviour analytics (UEBA), threat intelligence feeds, automated alerting and triage, and 24/7 security operations centre (SOC) coverage.