Practical guides for software companies, SaaS providers, product teams, hardware manufacturers and engineering leaders that need to build secure digital products and meet cybersecurity requirements such as the Cyber Resilience Act. We cover secure SDLC, product security, threat modeling, vulnerability management, SBOM, secure updates, DevSecOps, security testing, responsible disclosure and secure-by-design practices.
Threat Modeling for Embedded Systems: 5 Practical Steps
How do you model threats to a device that combines electronics, firmware and network communication? This guide covers five analysis stages, practical use of STRIDE and the conversion of threats into requirements and tests. A temperature-logger example explores service access, key protection and software updates. It also explains why signed firmware does not solve every update risk, why CVSS does not replace risk assessment and why the threat model must evolve with the product.
Prepared by: CCyber Editorial Team
Threat modeling for embedded systems examines a device and its environment from the perspective of potential misuse. The team identifies what needs protection, the paths through which the product could be affected, the consequences that matter and the safeguards that must be designed or verified.
Reviewing only the application communicating with a device is insufficient. An embedded-system assessment also needs to consider firmware, memory, service interfaces, updates and physical access. Its outputs should include threat scenarios, risk decisions, requirements and tests linked to a specific product version.
19 September 2026
The starting point is Sii’s article on threat modeling for embedded systems. The five-stage structure follows that material. Technical elaborations use the cited sources, while the device example, workshop questions and threat record are CCyber proposals, not descriptions of an actual client or discovered vulnerability.
Device manufacturers, firmware and electronics teams, architects, testers and product security owners. It also supports integrators and industrial system owners who want to understand which security assumptions to discuss with suppliers.
This article focuses on the device and its lifecycle. The broader guide “Threat modeling: praktyczny przewodnik dla zespołów produktowych” is available in the Secure Software and Digital Product Development category.
Threat modeling is a structured examination of how a system’s security could be compromised. It is not simply a list of known issues from vulnerability databases. It can assess a design that has not yet been implemented.
OWASP describes a repeatable process involving system understanding, threat identification, response selection and validation. Data flows and trust boundaries matter: these are points where permissions, control or assumptions about an information source change.
Practical distinction: unauthorized modification of device configuration is a possible threat scenario. Missing authorization checks could be a weakness enabling it. Establishing whether that weakness actually exists requires examination of the design or implementation.
Here, an embedded system means the electronics and software performing a defined device function. We do not automatically equate every embedded system with an IoT device or critical infrastructure component.
A device assessment should distinguish network, local and physical interfaces. The OWASP IoT Security Testing Guide separately addresses memory, firmware, update mechanisms and different interface types. Reviewing a web dashboard alone does not cover that entire scope.
Design question: does a safeguard still operate when the device is serviced, reset or disconnected from its cloud service? The answer may require changes to hardware, production procedures or support arrangements rather than only an application patch.
We recommend recording the hardware and firmware versions, device purpose, intended use and the specific function under review. Prepare descriptions of interfaces, stored data, updates and service modes. Also record the actual memory, power and response-time constraints.
Include people who understand electronics, software, testing and product operation. The product owner should participate in prioritization. Where a device affects the safety of people or processes, involve the person responsible for that discipline.
Cross-functional work and examination of design assumptions are supported by Microsoft’s Secure by Design practices. A security specialist can facilitate the assessment but cannot replace the designers’ knowledge of the device.
Our example is a fictional temperature logger that stores readings locally, sends them to a cloud service and supports firmware updates. It also has a local service interface. We assume that it neither controls machinery nor performs a functional safety protection role.
Identify the functions, information and product properties requiring protection. In this example, they include trustworthy measurements, alarm-threshold configuration, device identity and the ability to resume operation securely.
Include the surrounding environment: the operator, technician, cloud service and the infrastructure preparing and distributing updates. Not every component needs detailed analysis in the same session, but its dependencies should remain visible.
Stage output: agreed scope, protected assets, product versions and explicit exclusions. An assessment limited to network communication must not later be presented as a complete hardware review.
For the logger, describe measurement, configuration and update flows separately. Identify processes, persistent storage, the boot component that starts firmware and the service interface.
Example data flow: the sensor supplies a reading to the device software, which stores the result and sends it to the cloud service.
Example update flow: a package travels from the distribution system to the device, undergoes verification and only then becomes eligible for execution.
At each transition, ask who is trusted and what supports that trust. Physically placing a connector inside an enclosure is not itself an authorization mechanism. The model should show local access as well as internet connectivity.
Stage output: a flow model with trust boundaries and a list of points requiring verification.
Distinguish the capabilities of an unauthenticated remote user, a technician with limited permissions and someone with physical access. Do not assume that every attacker starts with complete control.
The example can consider device impersonation, unauthorized alarm-threshold changes and installation of older firmware. Record the conditions, required access and possible outcome for each scenario.
Example statement: someone able to initiate an update attempts to install an earlier signed version that should no longer be permitted. This is a hypothesis to test, not a claim that a particular product is vulnerable.
Stage output: scenarios connected to the system model rather than a generic list of terms such as “ransomware” or “network attack”.
Consider required access, execution difficulty, detectability and consequences for one device and the wider product fleet. Distinguish confirmed information from assumptions.
The Sii article mentions CVSS. FIRST provides an important clarification: a CVSS Base score measures vulnerability severity and should not be used alone to assess risk. Deployment and threat context require additional consideration. See the CVSS v4.0 User Guide.
In our example, not controlling machinery does not eliminate business consequences. Incorrect readings could prevent a reliable assessment of storage conditions. That consequence needs evaluation in the product’s actual application.
Stage output: justified priorities and identified information gaps. Avoid giving a seemingly precise score to a scenario whose conditions are not understood.
For selected threats, determine the response: redesign, restrict functionality, add protection or document a residual risk decision by the authorized owner. Assign an implementation owner and acceptance criterion to each change.
For the logger, this could involve restricting the service interface, protecting credentials or enforcing firmware-version rules. Selection should follow the scenario and platform capabilities rather than a list of fashionable technologies.
For firmware, consider protection against unauthorized changes, detection and secure recovery. These three directions are described in NIST SP 800-193.
Stage output: requirements and tests linked to threats. Merely recording “cryptography implemented” does not establish what has been protected.
Sii lists STRIDE, DREAD, PASTA, TRIKE, VAST and OCTAVE. This example uses STRIDE to organize scenarios. It is not a mandatory choice for every project.
The categories come from Microsoft’s documentation. The logger-specific questions below are CCyber examples.
Can the cloud service distinguish the intended logger from another device presenting the same identifier? How are the technician’s identity and the update source verified?
Can stored readings, alarm thresholds or firmware packages be changed without detection? Where does an integrity check actually influence the decision to accept information?
After a configuration change, can the team establish who performed it and what happened? What happens to the record during offline operation, a reset or storage exhaustion? The presence of a log alone does not establish its reliability.
Could diagnostics or memory access expose credentials? Could a secret obtained from one unit be used against other devices?
Could communication handling exhaust resources needed for measurement? What behaviour is expected during overload or loss of the cloud connection?
Can a read-only user change configuration or install firmware? Does service mode bypass restrictions enforced during normal operation?
STRIDE does not guarantee completeness. Microsoft emphasizes challenging design assumptions beyond the categories themselves. Asking what happens when a safeguard fails remains part of the assessment.
Establish where credentials originate, who provisions them during manufacturing and how they are changed or revoked. OWASP describes risks associated with secrets embedded in firmware, including the possibility of affecting multiple devices and making post-exposure changes difficult. See the OWASP firmware section.
Our proposed review also asks what happens when a device is replaced or changes ownership. Do not assume that resetting it always removes every item of information and authorization.
Signing a package, verifying its signature and enforcing permitted versions address different problems. A correctly signed older version can still be unacceptable. OWASP separately addresses signature validation, update authorization and downgrade protection in its update mechanism test catalogue.
The proposed design also needs an agreed recovery path after an interrupted update. Protection against returning to an unsafe version should not be designed without considering an available, trusted repair mechanism.
Review production, service and recovery modes separately. For each, establish the available functions, permissions and ability to detect an unwanted change.
The NIST device cybersecurity capabilities catalogue distinguishes areas including identification, configuration, data protection, interface control and updates. It supports selection of requirements for IoT devices rather than prescribing identical safeguards for every product.
Illustrative CCyber scenario. Assume the team is testing a logger and an earlier test version contains a known flaw that must not be reintroduced. This does not describe a real vulnerability in a particular manufacturer’s product.
Identifier and scope: TM-UPDATE-01, with the specified hardware revision, boot-component version and update mechanism.
Protected asset: the integrity of running software and the trustworthiness of measurements.
Scenario conditions: a person can access the update function and possesses an earlier signed package. Compromise of the signing key is not assumed.
Unwanted outcome: execution of a version below the approved minimum security level.
Proposed requirement: the normal update mechanism rejects such a package even when its signature is valid. Emergency recovery rules are defined separately and must not create an uncontrolled bypass.
Test: on a laboratory unit, verify rejection of the withdrawn version and successful acceptance of an approved version. Record which version actually starts after reboot.
Evidence and ownership: a report identifying the hardware and software build, test result, remediation owner and person assessing residual risk.
This is a template to adapt. Tests that disrupt normal operation belong on an agreed test bench, not on a device supporting production or a critical process.
Link the model to architecture, hardware and software versions. When a change occurs, check whether it introduces an interface, authentication method, service mode or supplier dependency. An incident or significant vulnerability may also require revision. OWASP describes maintaining the assessment alongside the system.
We recommend distinguishing identified, safeguard planned, implemented and verified. Separately flag scenarios awaiting information and risks formally retained by an authorized owner.
Before release, check that significant scenarios have a decision and the required tests were performed against the appropriate configuration. Do not treat the number of closed records as proof of complete security.
OWASP Threat Dragon can support diagrams and threat records. It helps document the model, but it does not verify actual interface behaviour or hardware resilience on the team’s behalf.
Determine the scope of applicable standards separately from selecting a technique such as STRIDE. The distinctions below use official scope descriptions rather than a review of every normative requirement.
IEC 62443-4-1 describes secure product development for industrial automation and control, including hardware, software and firmware. This part addresses product developers and maintainers. Its requirements should not automatically be assigned wholesale to device users. The scope is published by IEC.
ISO/SAE 21434 concerns cybersecurity engineering for electrical and electronic systems in road vehicles. It is not a universal standard for every embedded device. See the ISO description.
CLC/TS 50701 concerns cybersecurity in railway applications and their lifecycle. The description available from BSI also makes clear that it does not replace functional safety requirements.
A threat diagram alone does not establish conformity with a standard. The relevant scope, activities and evidence still need to be determined.
Connect the product model with an assessment of its operating environment. Segmentation, remote servicing and plant dependencies are explored in the OT, Industrial and Critical Infrastructure Security category. The linked CCyber blog resources are in Polish.
Customer network safeguards should not automatically be treated as a replacement for device protection. Deployment assumptions should be explicit and verifiable.
Through its cybersecurity project and implementation services, CCyber supports risk assessment, application security, secure development processes and OT environments.
Start with one significant device function. To define the support scope, prepare the product description, interfaces and changes planned for the next release. This helps establish the required designer involvement, assessment scope and any laboratory testing.
No internet connection does not eliminate local access, updates from removable media or service interfaces. The assessment scope may differ, but should reflect the actual ways the device can be affected.
No. It supports requirements and test planning, but does not demonstrate that implementation matches the design. Testing can reveal defects or assumptions that require model updates.
No. STRIDE organizes threat types. Scenario conditions, consequences and safeguard adequacy still need assessment. The number of identified categories is not a risk measure.
A signature helps verify package origin and integrity when correctly validated against a trusted key. It does not prove the code has no defects or that every older version should remain acceptable.
There is no universal duration. It depends on scope, documentation and complexity. Begin with a bounded function and turn missing information into follow-up actions. One meeting does not necessarily complete the assessment of the entire product.
Embedded-system threat modeling should connect electronics, firmware, communication and device operation. The five stages move from scope and flows to scenarios, priorities and safeguards.
The most important output is a verifiable design decision. The team should know what the product is protected against, which assumptions support that conclusion and how safeguards will be checked. That makes the model useful for the next device release as well.
How to Prepare a Digital Product for Security Testing and Certification?
Preparing a digital product for security testing and certification requires more than giving testers access to an application. A company should organize product scope, architecture, test environment, technical documentation, SBOM, threat model, vulnerability process, Secure SDLC evidence and regulatory requirements, especially under the Cyber Resilience Act.
Prepared by: CCyber Editorial Team
A secure preparation process for testing and certification should cover the full product scope, architecture, test environment, documentation, tester access, test data, component list, SBOM, threat model, security requirements and vulnerability handling process. Security testing verifies the product’s technical resilience. Certification or conformity assessment also requires process evidence: product risk, Secure SDLC, updates, technical documentation, test results, risk decisions and post-release vulnerability handling.
July 2026
Preparing a product for security testing means organizing everything testers need to perform a reliable test without wasting time guessing how the product works.
In practice, this means:
A well-prepared test produces better results because testers can focus on product risks instead of searching for access, documentation and basic information.
Preparing for certification or formal conformity assessment means preparing the product, process and evidence for verification against a defined set of requirements. Depending on the goal, this may involve CRA conformity assessment, cybersecurity certification, customer requirements, supplier audit or an industry standard.
Certification usually requires more than a penetration test. It may require showing:
Simply put: security testing checks the product in practice, while certification or conformity assessment also checks whether the company has process, evidence and product accountability.
Security testing is a technical verification of a product, application, API, infrastructure or component. Its goal is to find vulnerabilities, misconfigurations, logic flaws and risks that could be exploited by an attacker.
Typical test output:
Certification or conformity assessment verifies a product against requirements from a specific scheme, regulation, standard or security profile. It may include technical testing, but usually also covers documentation, process, roles, evidence and formal decisions.
Typical output:
Under the CRA, a manufacturer of a product with digital elements must demonstrate that cybersecurity requirements are met. For many products, manufacturer self-assessment will be possible. For some important or critical products, a notified body or stricter procedure may be required.
This is why the company should not assume that “certification” always means the same thing. First determine the product, regulation, scheme, category and assurance level that apply.
First, answer why the product is being tested or certified. Preparing for an API penetration test is different from preparing for CRA conformity assessment, EUCC certification or a large customer’s security questionnaire.
Example goals:
Evidence to prepare: short description of the purpose, expected outcome and recipient of the report or certification.
Scope is one of the most important preparation elements. Unclear scope leads to weak testing, misunderstandings and problems interpreting results.
The scope should include:
Evidence to prepare: test or conformity assessment scope document with systems, versions and exclusions.
Testers and auditors must understand how the product works. Without architecture, testing will be more superficial and certification may get stuck because documentation is missing.
Prepare:
Evidence to prepare: current architecture and data flow diagram.
The test environment should be as close to production as possible, but without risk to real customers, data and business processes.
The environment should have:
Production should not be used for testing without very clear rules, approvals, limits and risk assessment.
Evidence to prepare: test environment description, access data, testing rules and state restoration plan.
Test data should support realistic testing, but should not expose real customer or employee data.
Prepare:
Evidence to prepare: test data set and confirmation that it contains no production or confidential data.
Testers should have access to roles that reflect real product use. If the test covers authorization, accounts with different permission levels are needed.
Prepare:
Evidence to prepare: test account list, permission scope and access expiration date.
A threat model helps focus testing on the most important risks. It does not need to be perfect, but it should show what the team considers the product’s most important threats.
The model should include:
Evidence to prepare: threat model or list of the most important risk scenarios.
If the product will be assessed under CRA or B2B customer requirements, component visibility is very important. SBOM helps check dependencies, vulnerabilities, licenses and the impact of new vulnerabilities on the product.
Prepare:
Evidence to prepare: SBOM linked to a specific product version.
Before external testing, remove obvious issues. This prevents test budget from being used on problems the company could have detected internally.
The internal review should cover:
Evidence to prepare: list of issues fixed before testing and status of open risks.
Security testing needs clear rules. Testers should know what is allowed, what is prohibited, when to test, who to contact and how to report critical vulnerabilities.
The rules should define:
Evidence to prepare: testing rules approved by product and security owners.
A test does not end with the report. The key is what the company does with findings: how vulnerabilities are assessed, who fixes them, when retesting happens and what evidence is kept.
The process should include:
Evidence to prepare: test results handling procedure and remediation register.
If the goal is certification, conformity assessment or CRA preparation, the company should prepare a broader evidence pack than the test report.
The pack may include:
Evidence to prepare: structured product evidence folder ready for a customer, audit, assessment body or authority.
Checks the web application from the perspective of a user, attacker and business logic. It covers authentication, authorization, sessions, forms, files, errors, configuration and data access.
This is especially important for SaaS products, mobile applications and B2B integrations. It should verify object authorization, roles, tokens, rate limits, input validation and abuse of business flows.
This should cover the application, API communication, on-device data storage, token protection, configuration, reverse engineering and mobile platform-specific risks.
Checks environment configuration, network, access, privileged accounts, logging, data storage, cloud service configuration and deployment security.
Checks repositories, pipelines, secrets, artifacts, dependencies, signing, permissions and the possibility of injecting malicious code or components.
Should cover firmware, updates, communication, hardware interfaces, default configuration, keys, protocols, mobile application and backend.
This can be a preliminary readiness assessment. The goal is not only to find vulnerabilities, but to check whether the product and documentation are ready for a formal process.
Not every certification fits every product. A SaaS product, mobile application, router, firewall, cryptographic module, IoT device and hardware component may require very different approaches.
Before starting, check:
EUCC is an EU certification scheme based on Common Criteria. It can apply to ICT products such as technological components, hardware and software. It is more formal than a normal penetration test and requires security requirements, documentation and assessment by appropriate entities.
Not every software house will need EUCC immediately. However, it is worth understanding this direction if the product has security functions, is used in regulated sectors, will be sold to large customers or may fall into a category requiring a higher assurance level.
Many companies should start not with certification itself, but with readiness assessment. This shows whether the product has sufficient documentation, testing, processes, evidence and version control.
Readiness assessment helps avoid starting a formal process too early and discovering gaps that could have been prepared earlier.
Unclear scope leads to disputes, testing gaps and a report that is difficult to use. The scope must identify product, version, modules, accounts, APIs, integrations and exclusions.
If the test environment differs significantly from production, the test results may be less valuable. Differences should be described and consciously accepted.
Without realistic accounts, roles and data, testers cannot properly verify authorization, data separation, business flows and multi-tenancy in SaaS.
A test report is not automatically a certificate. It can be technical evidence, but certification or conformity assessment usually requires broader documentation and process.
If there is no triage, owners, remediation deadlines and retesting after the test, the report does not translate into real security improvement.
For conformity assessment and certification, missing documentation is one of the biggest problems. A product may be technically good, but difficult to formally confirm.
CRA requires process, documentation and evidence. This cannot be prepared in the last week before assessment. It is best to start with readiness assessment and an action plan.
A SaaS company prepares a B2B platform for a security test required by a large customer. The team wants to order a penetration test immediately, but quickly discovers that there is no current architecture diagram, the test environment differs from production, accounts for different roles are missing and the API is not well documented.
The company first prepares for testing. It defines the scope, creates test accounts, prepares test data for two customers, documents the API, collects documentation and runs internal dependency and secret scanning.
As a result, the external test becomes more valuable. Testers do not waste time organizing access. They check real risks: authorization, customer data separation, API, administrator panel, data export and integrations.
After the test, the company performs triage, fixes vulnerabilities and completes retesting. Then it uses the report as part of a broader evidence pack: SBOM, threat model, vulnerability register, update process and technical documentation for CRA.
ccyber.io helps companies prepare digital products for security testing, certification, conformity assessment and B2B customer requirements. We do not start from the test alone. First, we check whether the product, environment, documentation and processes are ready.
We can support your organization with:
The best first step is a short product readiness assessment. It shows whether the product is ready for testing, what is missing before conformity assessment and which actions should be completed before involving external testers or an assessment body.
No. Security testing detects vulnerabilities and technical risks. Certification or conformity assessment checks the product against defined requirements and usually requires broader documentation, process and evidence.
No. A test report can be important evidence, but CRA requires a broader approach: risk assessment, technical documentation, vulnerability handling, updates, SBOM, support period and user information.
No. For many products, manufacturer self-assessment will be possible. However, some important or critical products may require a stricter procedure or notified body involvement.
Test scope, test environment, user accounts, test data, role description, API description, architecture, testing rules, contact persons and a findings handling process.
API documentation, accounts and tokens with different roles, sample requests, test data, rate limits, authorization description, business scenarios and test environment.
In many cases, yes. SBOM is very important for CRA, vulnerability management, component assessment, customer responses and product technical documentation.
It is the state where the product has not only test results, but also scope, documentation, processes, evidence, owners and version control needed for formal assessment.
The best starting point is readiness assessment: scope, architecture, test environment, accounts, data, API, basic scanning, threat model and test findings handling plan.
Preparing a digital product for security testing and certification requires organizing the product, process and evidence. Simply giving testers access to an application is not enough if scope, environment, data, documentation and findings handling process are missing.
For companies preparing for CRA or large customer requirements, the broader approach is essential: risk assessment, technical documentation, SBOM, vulnerability process, security updates, threat model and Secure SDLC evidence.
The best order is: readiness first, then testing, then remediation and retesting, and only later formal certification or conformity assessment if required.
Secure Updates: How to Prepare a Product Update Process for CRA Requirements?
Secure updates for a digital product are not only about releasing a patch. Under the Cyber Resilience Act, a manufacturer should have a process for detecting vulnerabilities, preparing fixes, testing, signing, secure distribution, user communication, deployment monitoring and evidence documentation throughout the product support period.
Prepared by: CCyber Editorial Team
A secure update process for CRA should cover the entire patch lifecycle: vulnerability detection, risk assessment, change preparation, testing, approval, artifact signing, secure distribution, user communication, deployment monitoring and evidence documentation. A manufacturer of a product with digital elements should also define the support period, provide security updates without undue delay, prepare automatic updates where applicable and separate security updates from functionality updates where technically feasible.
July 2026
Secure updates are the process of preparing, verifying and delivering product fixes in a way that reduces vulnerability risk, avoids introducing new issues and prevents attackers from substituting a malicious product version.
In practice, a secure update process answers:
A secure update is not only about code. It also concerns the build process, change control, signatures, distribution channels, documentation, user support and vulnerability response.
The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements. One of the key areas is vulnerability handling throughout the product support period.
For manufacturers, this means the product should be designed and maintained so that the company can:
CRA therefore turns updates from a technical issue into a product, regulatory and business issue. The team must know not only how to release a fix, but also how to prove that the process works.
The manufacturer should have a process that makes it possible to respond to vulnerabilities and remediate them through security updates. This requires connecting vulnerability management, release process, testing, communication and documentation.
If the company is aware of a significant vulnerability, it should not delay a fix without justification. Priority should depend on risk, product exposure, active exploitation, customer impact and workaround availability.
A user should not be forced to install a large feature update only to receive a security fix if the two can be technically separated.
The CRA refers to automatic security updates in certain cases, especially for consumer products. At the same time, users should have a clear and easy mechanism to turn off automatic updates and temporarily postpone installation.
A security update should be accompanied by information explaining what it fixes, what the user should do and whether additional risk reduction actions are needed.
The user should know until when vulnerability handling and security updates can be expected. The support end date should be specified clearly, including month and year.
Updates cannot be managed well if the company does not know which products and versions are still supported. The first step is a product and version register.
The register should include:
Evidence to prepare: register of products, versions and support periods.
The update policy should define when the company releases a security fix, who makes the decision, how testing works and how users are informed.
The policy should include:
Evidence to prepare: security update policy approved by product and security owners.
A security update usually results from a vulnerability. The update process should therefore be connected with the vulnerability register, SBOM and risk assessment process.
For each important vulnerability, define:
Evidence to prepare: link between vulnerability, fix release and communication decision.
An attacker may try to replace the patch, compromise the build process, steal a signing key or inject malicious code into the release process. Update security therefore depends on development process security.
Check:
Evidence to prepare: build and release process description, approval logs and list of privileged users.
The user or system should be able to verify that the update comes from the correct manufacturer and has not been modified in transit.
In practice, this means:
Evidence to prepare: update signing procedure, key register and signature verification evidence.
The update distribution channel can be attacked. If an attacker compromises the update server, repository, administrator account or distribution system, they may try to deliver a malicious product version.
Security controls should cover:
Evidence to prepare: update channel diagram, access control, logs and contingency plan.
A security fix should not resolve one vulnerability while creating a new incident. Testing should cover both security and product stability.
Testing should include:
Evidence to prepare: update test report, release approval and list of known limitations.
For some products, automatic security updates are the best way to reduce risk. However, it is not always possible to install fixes automatically without affecting the user, production or integrations.
The process should define:
Evidence to prepare: description of the automatic update mechanism, user instruction and product decision register.
A security update should be understandable for the user. The communication does not need to disclose every technical detail before remediation, but it should clearly state what the user should do.
The communication may include:
Evidence to prepare: approved security advisory and communication channel list.
Releasing a fix does not mean that risk is gone. The company should know how many users installed the update, which versions remain vulnerable and whether problems appeared after the update.
Monitor:
Evidence to prepare: update adoption report and post-release issue list.
The CRA requires each security update made available to users during the support period to remain available after release for a minimum of 10 years or for the remainder of the support period, whichever is longer.
This means the manufacturer should plan:
Evidence to prepare: update retention policy and available version register.
Under CRA, security updates are part of the evidence that the manufacturer handles vulnerabilities and maintains the product securely. Evidence should be available in technical documentation or related registers.
Document:
Evidence to prepare: complete security update evidence pack.
In a SaaS model, the manufacturer usually controls the production environment and can deploy fixes faster. The challenge is change control, regression testing, customer communication and monitoring impact on integrations.
In SaaS, the following are especially important:
For software installed in the customer environment, the manufacturer often does not fully control the installation date. The update mechanism, notifications, instructions, compatibility and version monitoring where possible are therefore important.
Mobile applications depend on app stores, operating systems and user behavior. The company should plan how quickly the fix will reach the user and how to reduce risk for older versions.
In IoT and embedded systems, updates may involve firmware, resource-constrained devices, unstable connectivity and physical risk. Signatures, integrity verification, resilience to interrupted updates and safe recovery are particularly important.
If the company provides a component, library, SDK or API, it should prepare clear versioning, vulnerability advisories, update instructions and information for integrators. The customer must know how to safely update the component in their product.
If the company does not know which product versions it supports, it is difficult to decide which versions need a fix and which customers should be informed.
Time pressure after vulnerability discovery can lead to a rushed release. A security fix still needs testing, especially when it affects authentication, access, customer data or the installation process.
Unsigned or weakly protected updates can be replaced. For a digital product, the update mechanism is one of the most sensitive security elements.
An update may fail. The company should know how the product returns to operation, how data is protected and how the user receives support.
If the user must install a large feature change only to receive a security fix, delay and compatibility risk increase.
The user must know that an update is available, what it fixes and what they should do. Lack of communication extends exposure time.
If the company does not document tests, approvals, signatures, publication and communication, it is difficult to demonstrate compliance even if the update was done correctly.
A company develops a desktop application used by B2B customers in a regulated sector. The product has an update module, but no clear support policy, update signing is manual and customer communication is prepared only when a problem appears.
After a CRA analysis, the company realizes that it must organize the whole process. First, it creates a supported version register, defines the support period, assigns the update process owner and links vulnerabilities with fix releases.
Then the company introduces artifact signing, update installation tests, a failed update procedure and a security advisory template. It also adds an adoption report to see which customers still use older versions.
After 90 days, the company not only releases fixes faster, but also has evidence: who approved the fix, what was fixed, how it was tested, when it was published and how many customers installed it.
ccyber.io helps companies building digital products prepare a secure update process aligned with CRA requirements, Secure SDLC practices and the real way product teams work.
We can support your organization with:
The best first step is a short update process assessment. It helps determine which products require the most attention, where controls are missing and what should be implemented before CRA deadlines.
It is an update prepared, tested, signed, distributed and monitored in a way that reduces security risk without creating new risk for the user and product.
CRA refers to automatic security updates where applicable, especially for consumer products. Users should also have a clear opt-out mechanism and the ability to temporarily postpone installation.
CRA states that where technically feasible, security updates should be delivered separately from functionality updates. The goal is to avoid forcing the user to install a large feature change just to receive a security fix.
CRA indicates that security updates addressing identified security issues should be provided without delay and free of charge, unless otherwise agreed between the manufacturer and a business user for a tailor-made product.
CRA requires each security update made available to users during the support period to remain available after release for at least 10 years or for the remainder of the support period, whichever is longer.
Not always. The company should ensure a secure distribution channel, update integrity, user instructions, communication, testing, monitoring and evidence. Publishing the file alone may be insufficient.
Yes. The update process, vulnerability handling, testing, support and evidence should be linked to product technical documentation and conformity assessment.
The best starting point is a product and supported version register, security update policy, connection with the vulnerability register, update signing review and preparation of communications and evidence.
Secure updates are one of the most important parts of CRA compliance and real digital product security. A product that cannot be updated securely will be difficult to maintain, difficult to defend in front of customers and difficult to demonstrate in technical documentation.
The most important process elements are product register, support period, vulnerability management, testing, signing, secure distribution, automation where applicable, communication and update adoption monitoring.
Companies that prepare this process early will be better ready for CRA, customer questions, audits, incidents and situations where a critical security fix must be released quickly.
Vulnerability Management for Digital Products: Where Should You Start?
Vulnerability management for digital products does not end with scanning libraries or waiting for a penetration test report. Software companies should have a process for detecting, assessing, prioritizing, fixing, testing, communicating and documenting vulnerabilities throughout the product lifecycle, especially under the Cyber Resilience Act.
Prepared by: CCyber Editorial Team
Vulnerability management for digital products is a process for detecting, assessing, prioritizing, fixing, testing, communicating and documenting vulnerabilities in software, components, APIs, cloud, configuration, dependencies and the release process. A company should start with a product register, component register, vulnerability reporting channel, clear roles, risk classification, remediation deadlines, update process, SBOM, security testing and a reporting procedure under the Cyber Resilience Act.
July 2026
Vulnerability management for a digital product is an organized process for handling security weaknesses that may exist in the product, its components, configuration, libraries, APIs, cloud environment, release process or documentation.
In practice, the process answers the following questions:
Good vulnerability management does not mean that the company “has a scanner”. A scanner is only one source of information. The key is a process that turns vulnerability information into a decision, fix, test, communication and evidence.
A vulnerability is a weakness in a product, component, process or configuration that can be exploited to compromise security. It may affect code, dependencies, cloud settings, access control, business logic or the update process.
A bug is incorrect system behavior. Not every bug is a security vulnerability, but some bugs can lead to vulnerabilities. Example: an input validation bug may allow command injection or access control bypass.
Risk combines the likelihood of vulnerability exploitation and the impact on the company, product and customers. The same vulnerability may have a different risk level in different products.
An incident is an event that negatively affects or may negatively affect the security of a product, data or functions. A vulnerability can lead to an incident, but not every vulnerability means that an incident has already occurred.
The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements. For software companies, this means securing the product across its lifecycle: design, development, release, updates, vulnerability handling and user communication.
Under the CRA, the manufacturer must be ready for:
From 11 September 2026, reporting requirements apply for actively exploited vulnerabilities and severe incidents through the Single Reporting Platform. This means companies should not wait until 2027 to build the process. Without a vulnerability register, owners, classification and escalation path, meeting reporting deadlines will be difficult.
You cannot manage vulnerabilities effectively if the company does not know which products, versions and components it maintains. The first step is a digital product register.
The register should include:
Evidence to prepare: product and version register with owners and support status.
A large part of digital product vulnerabilities affects third-party components: libraries, packages, container images, transitive dependencies and tools used in the build process.
The company should prepare an SBOM, or Software Bill of Materials, and link it to a specific product version.
An SBOM helps answer:
Evidence to prepare: SBOM for key products, component register and SBOM update process for releases.
Vulnerabilities can be detected in many ways. The company should define which sources it uses and who monitors them.
Typical sources:
Evidence to prepare: list of vulnerability sources, monitoring owners and review frequency.
A company creating a digital product should have a clear way to receive vulnerability reports. Without it, a researcher, customer or partner may not know where to report a problem.
Prepare:
Evidence to prepare: vulnerability disclosure policy, public contact channel and report handling procedure.
The vulnerability register is the center of the process. It should collect all vulnerabilities regardless of source: scanner, customer, penetration test, researcher, incident or supplier information.
The register should include:
Evidence to prepare: central vulnerability register with decision and action history.
Not every high-score vulnerability means the product is truly exposed. Conversely, a medium-score vulnerability may be critical if it affects a public feature, customer data or administrative access.
When assessing a vulnerability, consider:
Evidence to prepare: classification decision with justification, not only scanner score.
The company should have internal response and remediation timelines. Deadlines depend on vulnerability severity, product exposure, fix availability and real risk.
Example model:
Timelines should not be copied mechanically from the internet. They should follow risk appetite, customer requirements, regulations and team capacity.
Evidence to prepare: remediation timeline policy and history of meeting deadlines.
A good fix should not only change one line of code if the problem comes from a weak design pattern, missing tests or poor access control.
For every important vulnerability, ask:
Evidence to prepare: root cause description, fix, regression test and preventive actions.
A vulnerability fix should be tested. Otherwise, the company does not know whether the problem is really gone or whether a new issue was introduced.
Verification may include:
Evidence to prepare: retest result and confirmation of vulnerability closure.
If a vulnerability affects customers or users, communication must be planned. Not every vulnerability requires a public advisory, but every important vulnerability should have a communication decision.
A security advisory may include:
Evidence to prepare: approved advisory, recipient list, publication date and update history.
From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents affecting product security through the Single Reporting Platform.
The process should specify:
Evidence to prepare: CRA reporting procedure, role list, note templates and reporting register.
Every serious vulnerability is an opportunity to improve the process. The company should analyze not only how quickly it fixed the issue, but why it appeared and whether similar mistakes can be prevented.
After an important vulnerability, run a short review:
Evidence to prepare: lessons learned note and improvement actions.
CVSS is a useful standard for technical severity assessment, but it should not be the only remediation priority criterion. A digital product has its own context: customers, data, exposure, architecture, mitigating controls and contractual obligations.
A vulnerability actively exploited by attackers should have higher priority than a theoretical vulnerability with a similar technical score. Under the CRA, active exploitation may trigger reporting obligations if it affects a product with digital elements.
EPSS can support the assessment of the probability that a vulnerability will be exploited in the near future. It does not replace team judgment, but helps distinguish vulnerabilities that are only “technically high” from those more likely to be exploited.
A vulnerability in an internet-facing feature has a different priority than a vulnerability in a component that is not externally reachable and is not used in the product.
If a vulnerability can lead to access to customer data, personal data, financial data, secrets, API keys or multi-tenant SaaS data, the priority should increase.
Sometimes a quick library update removes significant risk with low effort. In other cases, a fix requires architecture changes. Prioritization should consider both risk and a realistic remediation plan.
A scanner can find a vulnerability, but it will not define owner, priority, deadline, communication, customer impact or reporting obligations. The company needs a process, not only a tool.
If a vulnerability is not linked to a specific product version, it is difficult to determine which customers are exposed and whether the fix was deployed.
If a researcher or customer does not know where to report a vulnerability, the information may go to the wrong person, be ignored or be published without coordination.
CVSS is important, but not enough. Remediation priority must consider product, customers, exposure, active exploitation and fix availability.
Closing a task in a project system does not mean the vulnerability was effectively removed. Retesting or another form of confirmation is needed.
Not every vulnerability requires a public advisory, but lack of any communication decision can create chaos when a customer asks about risk.
Companies covered by CRA must be ready to report actively exploited vulnerabilities and severe incidents. Without procedures and roles, meeting deadlines will be difficult.
A SaaS company develops a platform for B2B customers. The product has a web application, API, reporting module, several integrations and hundreds of open-source dependencies. A regulated sector customer asks how the company handles vulnerabilities and how quickly it can respond to a new vulnerability in a popular library.
At first, the team checks vulnerabilities manually. Some dependencies are in different repositories, some in container images and some in build tools. There is no single vulnerability register and no clear decision on who approves customer communication.
The company implements a vulnerability management process. It creates a product register, generates an SBOM for the main application, starts dependency scanning, prepares a vulnerability reporting channel, defines remediation deadlines and prepares a security advisory template.
After 90 days, the company can answer the customer clearly: which products are covered by the process, how vulnerabilities are detected, how they are assessed, what remediation deadlines apply, how communication works and what evidence can be shown.
ccyber.io helps software companies implement a practical vulnerability management process for digital products, aligned with CRA, Secure SDLC, SBOM and B2B customer requirements.
We can support your organization with:
The best first step is a short vulnerability process assessment. It helps determine where the biggest gaps are, whether the company is ready for CRA and which actions should be implemented in the first 30, 60 and 90 days.
It is the process of detecting, assessing, prioritizing, fixing, testing, communicating and documenting vulnerabilities in a product, its components, configuration, APIs, cloud and release process.
No. A scanner helps detect issues, but it does not replace a process. Roles, decisions, priorities, deadlines, fixes, tests, communication and evidence are required.
A vulnerability is a weakness that can be exploited. An incident is an event that already affects or may affect the security of a product, data or functions.
It is useful to combine CVSS, active exploitation, EPSS, product exposure, data criticality, customer impact, fix availability and regulatory or contractual requirements.
Yes, especially for digital products. SBOM helps determine which components and versions are in the product and whether a new vulnerability affects a specific release.
CRA requires manufacturers of products with digital elements to handle vulnerabilities, document them, provide security updates and report actively exploited vulnerabilities and severe incidents according to defined timelines.
No. CRA focuses on actively exploited vulnerabilities and severe incidents affecting product security. The company should have a procedure to assess whether a reporting obligation exists.
The best starting point is a product register, vulnerability register, reporting channel, basic risk classification, dependency scanning, SBOM for the main product and clear remediation deadlines.
Vulnerability management for digital products is one of the most important elements of product security. Finding a vulnerability is not enough. It must be assessed, fixed, tested, documented and, where needed, communicated or reported.
For software companies, this process is becoming increasingly important from both business and regulatory perspectives. Customers want evidence, auditors want a process and the CRA strengthens manufacturer obligations for vulnerabilities, updates and reporting.
The best approach is to start simply: product register, SBOM, vulnerability register, owners, priorities, deadlines, tests and communication procedure. Automation, scaling and integration with the full Secure SDLC can come next.
Software Bill of Materials (SBOM): What Software Companies Must Prepare for CRA
An SBOM, or Software Bill of Materials, helps a company show which components, libraries and dependencies make up a digital product. Under the Cyber Resilience Act, software companies should prepare an SBOM generation process, dependency control, vulnerability management, technical documentation and a way to share information with customers, auditors and market surveillance authorities.
Prepared by: CCyber Editorial Team
An SBOM, or Software Bill of Materials, is a formal and structured record of components, libraries, dependencies and relationships that make up a digital product. Under the Cyber Resilience Act, software companies should prepare a process for generating SBOMs in a machine-readable format, link SBOMs to vulnerability management, technical documentation, security updates and compliance evidence.
July 2026
An SBOM is a structured record of components used in software. It can be compared to an ingredients list for a product. In physical manufacturing, a company knows which parts a device contains. In software, an SBOM plays a similar role.
An SBOM helps answer:
The most important point is that an SBOM is not a goal by itself. It is a tool for software supply chain visibility, vulnerability management, customer responses and compliance evidence.
The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements. This includes hardware and software products made available on the EU market.
The CRA requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements. It explicitly refers to drawing up an SBOM in a commonly used and machine-readable format, covering at least the top-level dependencies of the product.
In practice, a company creating a digital product should know what the product is made of. When a new vulnerability appears in a popular library, the company must quickly determine:
Without an SBOM, answering these questions often requires manual searching across repositories, pipelines, container images, documentation and assumptions about what actually reached the release.
The CRA states that manufacturers must identify and document vulnerabilities and components contained in products with digital elements, including by drawing up an SBOM. Such an SBOM should be in a commonly used and machine-readable format and cover at least the top-level dependencies of the product.
In practice, companies should treat SBOM as one of the key elements of CRA preparation, alongside:
Important: an SBOM does not automatically mean public disclosure of the full component list to every user. Under CRA, technical documentation, including the SBOM, may be requested by market surveillance authorities. If the manufacturer decides to make the SBOM available to users, information on where it can be accessed should be provided.
The minimum SBOM scope depends on the standard, tool and use case. For companies preparing for CRA, the SBOM should be practical, current, machine-readable and linked to a specific product version.
Top-level dependencies are components that the product uses directly. Example: an application directly uses a library for authentication, file handling, logging or database communication.
Transitive dependencies are components used by other components. Example: your application uses library A, and library A uses library B. Library B is a transitive dependency.
The CRA refers to at least top-level dependencies. However, from a real vulnerability management perspective, companies should aim to gain visibility into transitive dependencies as well. Many serious vulnerabilities appear in libraries that were not manually added by the team, but entered the product through other packages.
Practical recommendation for software companies:
SPDX is an open standard developed by the Linux Foundation. It is used to describe software components, licenses, dependencies and supply chain information. The SPDX specification is available as the international standard ISO/IEC 5962:2021.
SPDX works well where license compliance, customer exchange and interoperability between tools matter.
CycloneDX is an OWASP standard for bills of materials, designed with software supply chain cybersecurity in mind. It supports SBOM, SaaS bills of materials, cryptography bills of materials, hardware bills of materials and AI bills of materials.
CycloneDX is often used in DevSecOps teams for automatic SBOM generation, vulnerability analysis and integration with security tools.
There is no single answer for every company. More important than the format itself is whether the SBOM is current, machine-readable, generated repeatedly, linked to a product version and used in vulnerability management.
In practice, choose a format supported by the company’s tools, customer requirements and future regulatory needs. In many organizations, supporting both SPDX and CycloneDX can be useful if tools and processes allow it.
An SBOM has the greatest value when it is used operationally. A file stored in a repository does not reduce risk if nobody analyzes it.
A good process should work as follows:
An SBOM may show that a product contains a vulnerable component. This does not always mean the vulnerability is exploitable in the product. The team should assess context: whether the vulnerable function is used, whether the component is reachable, whether a mitigating control exists and whether the product is exposed to the internet.
This is why VEX is increasingly used alongside SBOM. VEX is a way of communicating whether a vulnerability actually affects a specific product.
SBOM answers the question: which components make up the product?
VEX answers the question: does a specific vulnerability in a component affect this product in practice?
Example:
For companies selling B2B software, combining SBOM and VEX can significantly reduce chaotic customer questions after a new vulnerability is disclosed in a popular library.
SBOM should not be only one developer’s task. It is part of product security, vulnerability management and compliance. The owner may be product security, DevSecOps, CTO, security engineer or the team responsible for product quality.
Evidence to prepare: SBOM process owner, responsibility scope and supporting people.
At the beginning, not everything needs to be covered. Start with products that are most important for the business, covered by CRA, sold to B2B customers or containing sensitive data.
Priority:
Evidence to prepare: list of products and versions covered by the SBOM process.
Choose a format supported by the team’s tools and customer requirements. In most cases, SPDX or CycloneDX should be considered.
When choosing a tool, check:
Evidence to prepare: decision on format, tool and SBOM generation scope.
Manual SBOM creation quickly stops working. The product changes with every release, and dependencies are updated frequently. The SBOM should be generated automatically during build or release.
Automation should cover:
Evidence to prepare: automatic SBOM generation configuration and sample file for a product release.
An SBOM that is not linked to a product version has limited value. When a customer asks about a vulnerability in a specific version, the company must know which SBOM applies to that version.
Link SBOM to:
Evidence to prepare: product release register with assigned SBOM.
After an SBOM is generated, it should be used to assess vulnerabilities. The SBOM alone is not enough. Component analysis against vulnerability information sources is needed.
The process should include:
Evidence to prepare: vulnerability report, triage decisions, remediation tasks and remediation confirmation.
An SBOM may be incomplete, incorrect or inconsistent. Tools do not always detect components in the same way. This is why quality review is needed.
Check:
Evidence to prepare: SBOM quality checklist and validation result.
An SBOM may contain sensitive business or technical information. The company should define who receives it, when and at what level of detail.
Possible models:
Evidence to prepare: SBOM sharing policy, approval path and customer response template.
An SBOM must change together with the product. If the product has a new release, new dependencies or a new container image, the SBOM should also be updated.
If it is not clear which SBOM applies to which product version, answering a customer or authority question becomes difficult. SBOM must be tied to a specific release.
Generating the file alone does not reduce risk. SBOM should feed vulnerability assessment and update processes.
Tools may produce different results. SBOM should be validated and checked for completeness, correctness and usefulness.
An SBOM may reveal information about architecture, dependencies and potential product weaknesses. The company should define who receives this information and at what level of detail.
If nobody owns SBOM, the process will quickly fall apart. An owner is needed in product security, DevSecOps, engineering or security.
In B2B products, some components may come from a customer, integrator or supplier. It is important to define who is responsible for describing them, tracking vulnerabilities and applying updates.
SBOM should be linked to product technical documentation. Under CRA, technical documentation should show how the product was designed, developed and maintained from a cybersecurity perspective and how the manufacturer handles vulnerabilities.
In the documentation, connect SBOM with:
A good SBOM also helps with customer communication. When a new vulnerability appears, the company does not need to answer generally. It can check the impact on specific products and versions.
The company has the first component list, but the process is manual, irregular and not connected with product releases.
The company uses a tool to generate SBOM for a selected product, but does not always do it for every release.
SBOM is generated automatically at release, linked to product version and stored as evidence.
SBOM feeds vulnerability management. The team can quickly answer whether a new vulnerability affects the product.
SBOM becomes part of technical documentation, CRA processes, customer responses, audits and software supply chain risk management.
A SaaS company develops a B2B platform. The product uses hundreds of open-source components, several container images, a web application, API and reporting module. A regulated sector customer asks whether the company can identify which component versions are in the product and whether a vulnerability in a popular library affects their environment.
At first, the team checks dependencies manually. It turns out that different repositories use different library versions, containers contain additional packages and documentation does not show which components reached a specific release.
The company implements an SBOM process. First, it generates SBOMs for the main application and container images. Then it links SBOMs to product versions, adds vulnerability scanning, prepares a procedure for sharing information with customers and includes SBOM in product technical documentation.
After several weeks, the company can answer customer questions faster and manage vulnerabilities better. SBOM stops being an audit document and becomes an operational tool.
ccyber.io helps software companies prepare an SBOM process in a practical way aligned with CRA, vulnerability management and the real product development process.
We can support your organization with:
The best first step is a short SBOM readiness assessment. It helps determine which products need SBOMs, what tools are available, how the release process works and what must be prepared before the CRA deadlines.
An SBOM is a formal record of components and supply chain relationships in software. It shows which libraries, packages, modules and dependencies make up a digital product.
The CRA states that manufacturers must identify and document vulnerabilities and components in products with digital elements, including by drawing up an SBOM in a commonly used and machine-readable format, covering at least top-level dependencies.
The CRA refers to at least top-level dependencies. From a practical perspective, however, visibility into transitive dependencies is valuable because many vulnerabilities appear there.
Not always. An SBOM may be internal or shared with customers or authorities under defined conditions. The company should define sharing rules because an SBOM may contain sensitive information.
SPDX or CycloneDX are the most common options to consider. The choice should depend on tools, customer requirements, CI/CD process, vulnerability analysis needs and future regulatory requirements.
No. SBOM shows components and dependencies, but it does not replace application testing, code review, API testing, threat modeling or architecture assessment.
SBOM shows what is in the product. VEX helps communicate whether a specific vulnerability actually affects a product and its usage context.
The best starting point is one pilot product: choose a format, generate the first SBOM, link it to a product version, check vulnerabilities and prepare an update and sharing procedure.
SBOM is becoming one of the key elements of digital product security. Under CRA, it is not enough to know that a product “uses open-source libraries”. The company must be able to show which components are in the product, how they are documented, how they are monitored and how they support vulnerability management.
The best approach is to treat SBOM as a process, not a one-time file. SBOM should be generated automatically, linked to a product version, analyzed for vulnerabilities and stored as part of technical documentation.
Companies that prepare the SBOM process early will be better ready for CRA, customer requirements, audits, vulnerability incidents and growing expectations around software supply chain transparency.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.