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: A Practical Guide for Product Teams
Threat modeling helps product teams identify security problems during design, before they reach code and production. Learn how to run a practical session, what questions to ask, how to use STRIDE, how to document results and how to turn threats into concrete tasks for the team.
Prepared by: CCyber Editorial Team
Threat modeling is a practical method for analyzing a product, feature or architecture to understand what can go wrong from a security and privacy perspective. Product teams should start with four questions: what are we working on, what can go wrong, what are we going to do about it and did we do a good enough job? The outcome of a good session is not only a diagram, but a list of risks, decisions, security requirements, tests and implementation tasks.
July 2026
Threat modeling is the analysis of a product, feature, process or architecture from the perspective of possible threats. The goal is to find security and privacy problems before they become embedded in code, configuration, integration or a business process.
In practice, threat modeling helps answer four questions:
Well-run threat modeling is not an academic exercise. It is a workshop designed to improve design, reduce risk and create tasks the team can actually implement.
Product teams make decisions that directly affect security: how login works, who can access data, how the API behaves, where customer boundaries exist in SaaS, what integrations can access the system and how the product handles errors.
If security appears only during a penetration test before release, many architecture decisions are already hard to change. Threat modeling moves the discussion earlier, where fixes are cheaper and less painful.
Threat modeling helps:
The best moment is during concept, architecture or first version planning. At that stage, the team can still change the approach to data, authentication, integrations and permissions without high cost.
Not every small change requires a full session. Threat modeling is especially useful for features that have higher security impact.
Examples of high-risk features:
Threat modeling is useful during cloud migration, identity provider changes, new API deployment, microservices adoption, data model changes or new integrations.
If the company had an incident or found a serious vulnerability, threat modeling helps determine whether the problem was isolated or caused by weak design assumptions.
Threat modeling can support preparation for CRA, NIS2, ISO/IEC 27001, SOC 2, customer requirements or product conformity assessment.
The most common mistake is a scope that is too broad. A session called “let’s model the whole system” can quickly become chaotic and produce no actionable result. It is better to start with a specific feature, service, module or data flow.
Good scope examples:
Evidence to prepare: short description of session scope and modeling objective.
Threat modeling should not be a solo security exercise. The best results come when people who understand the product, architecture, data, users and business risk participate.
Typical session participants:
The goal is not a large group. The goal is the right group. A 5-7 person session often works better than a full department meeting.
Evidence to prepare: participant list, roles and owner of session outputs.
The model does not need to be perfect. It should help the team see how the system works. A data flow diagram, architecture diagram or process map is usually enough.
The model should show:
Evidence to prepare: system diagram or data flow diagram with trust boundaries.
Not all data has the same risk level. The team should know which data is public, internal, confidential, personal, financial, medical, technical or covered by business secrecy.
Useful questions:
Evidence to prepare: data list, classification and processing locations.
A trust boundary is a place where data or a request crosses between areas with different levels of control. This is often where important risks appear.
Examples of trust boundaries:
Evidence to prepare: diagram with trust boundaries and description of controls at those boundaries.
First, the team must understand the scope together. The product owner explains the feature, the architect shows the model, developers add details and security helps identify risk areas.
Define:
At this stage, the team identifies threats. You can use STRIDE, an OWASP checklist, previous incidents, customer requirements, MITRE ATT&CK or simple brainstorming.
Example questions:
STRIDE helps organize the discussion. It is not the only method, but it is practical and works well with product teams.
STRIDE includes:
For each element of the model, ask which STRIDE categories are relevant. This does not have to be mechanical for every field. The goal is to find real threats, not to fill in a table.
Not every threat is equally important. After threats are identified, decide which require action now, which can be planned later and which can be consciously accepted.
When assessing risk, consider:
In practice, a simple scale is enough: critical, high, medium, low. The important thing is that the team understands why a risk has a given priority.
For every significant threat, define a response. The most common options are: mitigate the risk, remove the feature or risk source, transfer responsibility or consciously accept the risk.
Good mitigation actions should be concrete:
If the response does not lead to a task, requirement or test, it is probably too general.
The biggest value appears when threat modeling outputs enter the team’s work. Risks should become backlog tasks, security requirements, tests, decisions or risk acceptances.
For every significant threat, define:
At the end of the session, the team should check whether the model makes sense and whether outputs are useful.
Control questions:
In SaaS, customer data separation is critical. One of the most important questions is: can customer A accidentally or intentionally see customer B’s data?
Check:
The administrator panel is often high risk because it provides broad permissions. The model should check who can access it, how it is protected and what actions can be performed from it.
Check:
In SaaS, APIs are often the main attack surface. Authorization errors, no rate limits, overly broad tokens and unsafe integrations can lead to serious incidents.
If the product uses AI or agents that automate actions, threat modeling should include new risks: prompt injection, data disclosure from context, excessive agent permissions and overreliance on AI output.
If threat modeling happens after the feature is built, the team may discover problems that require major architecture changes. It is better to do it early.
Trying to model the entire platform in one session usually leads to shallow analysis. It is better to model smaller parts more thoroughly.
Security and developers may not know the full business context. Product owners help explain how the feature should work, what matters to customers and which risks are most important.
Tools can help, but they do not replace thinking. Threat modeling is mainly about conversation, understanding the system and making decisions.
If the session produces no tasks, requirements or tests, threat modeling does not affect the product. Outputs must enter the development process.
The product changes. The threat model should be updated after major architecture changes, new integrations, new data types and new high-risk features.
The diagram should support the conversation, not become a work of art. A simple diagram the team understands is better than a perfect model nobody uses.
A SaaS company is planning a new customer data export feature through API. The feature will allow customers to download large reports and integrate with external analytics systems.
The product team organizes a 90-minute threat modeling session. The diagram shows the user, API, authorization service, database, job queue, file storage and external customer system.
During the session, the team identifies several risks: a customer may download another customer’s report, the API token may have overly broad permissions, the export may reveal data in logs, the feature may be abused to overload the system and the report link may remain valid for too long.
The session outputs go into the backlog: object-level access control, shorter link lifetime, rate limiting, removal of sensitive data from logs, authorization tests and monitoring of unusual exports.
As a result, the team finds problems before most of the code is written. A later penetration test confirms that the key risks were already reduced during design.
ccyber.io helps product teams, software houses and SaaS companies run threat modeling in a practical, lightweight way connected with the team’s real work.
We can support your organization with:
The best first step is a pilot workshop for one high-risk feature. This lets the team quickly see the value of the method and implement a simple, repeatable process without unnecessary bureaucracy.
No. The best threat modeling involves product owners, developers, architects, DevOps, testers and security. Security can facilitate, but product and technology context must come from the team.
No. At the beginning, a diagram, whiteboard, document and simple template are enough. Tools can help later when the company wants more repeatability and scale.
For one high-risk feature, 60-90 minutes is often enough. For a larger system, it is better to run several smaller sessions than one very long meeting.
No. STRIDE is a popular and practical structure, but it is not the only method. Teams can also use other approaches, checklists, attack scenarios, MITRE ATT&CK, OWASP ASVS or a custom method suited to the organization.
It should be done before development of high-risk features, during architecture changes, new integrations, new data flows, AI features, administrator panels and APIs.
The output should include concrete threats, risk assessment, decisions, security requirements, backlog tasks, tests, owners and deadlines.
Yes. CRA requires product security across the lifecycle. Threat modeling helps prepare product risk assessment, security requirements, documentation and design evidence.
No. Threat modeling does not replace testing. It helps find problems earlier and plan tests better. The best approach combines threat modeling, code review, automated testing and manual testing.
Threat modeling is one of the most practical tools for product teams that want to build more secure software without waiting for a penetration test at the end of the project.
The key is a simple approach: define scope, understand the system, mark data and trust boundaries, identify threats, choose responses, turn outputs into tasks and return to the model when major changes happen.
Good threat modeling does not create documentation for its own sake. It creates better product decisions, better security requirements, better tests and lower risk for customers and the company.
Secure SDLC Checklist for SaaS Companies and Software Houses
Secure SDLC helps SaaS companies and software houses build security into the entire software development lifecycle: from requirements and architecture, through coding, testing and CI/CD, to release, monitoring, updates and vulnerability handling. Use this practical checklist to reduce risk, prepare evidence and meet customer and regulatory requirements.
Prepared by: CCyber Editorial Team
Secure SDLC is a secure software development lifecycle, meaning an approach where security is present from requirements and architecture to deployment, monitoring, updates and vulnerability handling. SaaS companies and software houses should start with a checklist covering product security ownership, security requirements, threat modeling, coding standards, code reviews, SAST, DAST and SCA testing, SBOM, CI/CD security, secrets management, vulnerability management and evidence.
July 2026
Secure SDLC means secure software development lifecycle. It means embedding security into every stage of product development: idea, requirements, architecture, development, testing, deployment, maintenance, updates and vulnerability handling.
In practice, Secure SDLC answers the following questions:
Secure SDLC does not have to slow development down. Implemented well, it reduces chaos, limits late-stage rework and helps find problems earlier, when they are cheaper to fix.
SaaS companies and software houses build software that often processes customer data, integrates with external systems, uses cloud, APIs, open-source components and automated deployments. This creates a large attack surface.
Customers increasingly expect not only a statement that “we care about security”, but specific evidence:
Secure SDLC is also increasingly important from a regulatory perspective. The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements, and customers covered by NIS2, DORA or ISO/IEC 27001 may transfer security requirements to technology suppliers.
Product security cannot belong to nobody. The company should have an owner for application or product security. In a small company, this does not need to be a separate department, but responsibility must be clear.
The owner should coordinate:
Evidence to prepare: decision naming the product security owner, responsibility scope and supporting team list.
You cannot secure a product that is not described clearly. SaaS companies and software houses should maintain a list of products, repositories, applications, APIs, services, libraries, components and environments.
The register should include:
Evidence to prepare: product and repository register with owners and criticality classification.
Security should not be an add-on to functionality. It should be part of requirements. Product owners, architects, developers and security should know what security requirements the product must meet.
Example requirements:
Evidence to prepare: product security requirements linked to backlog, risk and tests.
Threat modeling helps the team answer: what can go wrong and how can we prevent it? Not everything needs to be modeled immediately. Start with high-risk features.
Threat modeling is useful for:
The output should be concrete requirements, backlog tasks and tests.
Evidence to prepare: data flow diagram, threat list, control decisions and remediation tasks.
A secure coding standard should be simple, practical and aligned with the technologies used by the team. It should not be a document nobody reads.
The standard should cover:
Evidence to prepare: coding standard, pull request checklists and team training confirmation.
Passwords, API keys, tokens, certificates and other secrets should not end up in code repositories, tickets, documentation, chat tools or unprotected configuration files.
Minimum rules:
Evidence to prepare: secrets policy, vault configuration, scanning results and rotation register.
Modern applications use many libraries and packages. This accelerates work, but introduces software supply chain risk.
The company should know:
Evidence to prepare: dependency register, SCA results and procedure for updating vulnerable components.
SBOM, or Software Bill of Materials, helps show what the product is made of. It is important for supply chain security, CRA, customer discussions and rapid response to new vulnerabilities.
A good SBOM should be:
Evidence to prepare: SBOM for the main product and the SBOM update process.
The code repository is one of the most important assets of a technology company. Repository compromise can lead to source code leakage, secret exposure, code tampering or attacks on customers.
Minimum controls:
Evidence to prepare: repository configuration, MFA status, branch protection rules and access review report.
The CI/CD pipeline can become an attack path into the product. If an attacker compromises the build or deployment process, they may introduce malicious code into a legitimate product release.
Control:
Evidence to prepare: pipeline documentation, permission list, secrets configuration, deployment logs and production approval rules.
Security testing should be part of the development process, not only a pre-release activity. For SaaS companies and software houses, the minimum baseline is a combination of several testing methods.
In practice:
Not every tool warning is critical. A triage process is needed to decide which findings are real and require remediation.
Evidence to prepare: SAST, DAST, SCA and secret scanning results, triage decisions and remediation status.
In SaaS products, API is often the most important attack surface. Authorization, object access control, rate limits and customer data separation issues can lead to serious incidents.
API testing should cover:
Evidence to prepare: API test plan, test results, vulnerabilities and remediation confirmation.
Configuration errors are one of the most common causes of incidents in cloud and SaaS services. Development, test and production environments should be separated and managed according to clear rules.
Check:
Evidence to prepare: environment standard, configuration review results and production access control report.
The product should generate logs that help detect incidents, analyze events and prove what happened. No logs means no visibility.
Useful events to log:
Logs must be protected from tampering, available for analysis and retained according to company rules and customer requirements.
Evidence to prepare: list of logged events, log retention, alerts and monitoring report.
Vulnerabilities do not end on release day. The company must have a process for receiving reports, assessing issues, fixing them, communicating and documenting them.
The process should include:
Evidence to prepare: vulnerability management procedure, vulnerability register, remediation status and retest reports.
A good Secure SDLC checklist ends with evidence. Customers, auditors and regulators increasingly ask not only whether the company “does security”, but whether it can prove it.
Key evidence:
Evidence to prepare: Secure SDLC evidence pack ready for customers, audits or conformity assessment.
If security appears only at the end, the team has little time for fixes and costs increase. Security should be part of requirements, design and daily work.
A small software house does not need to build a large corporate programme immediately. It is better to start with a minimum that works and gradually increase maturity.
If nobody owns Secure SDLC, security tasks will be postponed. The owner does not need to do everything alone, but must coordinate the process.
The modern delivery process is a critical security element. A compromised pipeline can be as dangerous as an application vulnerability.
An application may be well written and still vulnerable because of a library, package or third-party component. That is why SCA and SBOM matter.
A product’s life does not end on deployment day. Vulnerabilities will appear later, so the company needs a process for detection, assessment, remediation and communication.
The team may do many good things, but without evidence it is hard to show maturity to a customer, auditor or regulator.
A SaaS company develops a platform for B2B customers. It has several development teams, fast deployments, many API integrations, a cloud environment and increasing customer security requirements.
Until now, security was based mainly on annual penetration testing. After each test, the team received a long list of vulnerabilities that had to be fixed under time pressure.
After implementing Secure SDLC basics, the company changes its approach. It introduces security requirements into the backlog, performs threat modeling for high-risk features, adds secret and dependency scanning to CI/CD, prepares an SBOM and creates a vulnerability handling process.
After 90 days, the company is not “perfectly secure”, but it has much better control. It knows which products are critical, which vulnerabilities are open, which dependencies are used and what evidence it can show to customers.
ccyber.io helps SaaS companies and software houses implement Secure SDLC in a practical, lightweight way aligned with how development teams actually work.
We can support your organization with:
The best first step is a short Secure SDLC assessment. It helps identify which parts of the process already work, where the biggest gaps are and what should be implemented in the first 30, 60 and 90 days.
No. Small and medium-sized companies can also implement Secure SDLC, but they should start with simple practices: security requirements, code reviews, dependency scanning, secrets control and vulnerability handling.
No. Penetration testing is important, but it does not replace a secure development process. Secure SDLC helps find and fix issues earlier, before they reach production.
The best starting point is a product register, security owner, security requirements, repository control, secret and dependency scanning and a pilot on one product.
Secure SDLC describes the full secure software development lifecycle. DevSecOps is a practical way of embedding security into DevOps work, automation, CI/CD, testing and deployment.
SBOM is increasingly useful, especially for companies selling software to B2B customers, preparing for CRA, serving regulated sectors or managing many open-source components.
Yes. Secure SDLC helps prepare processes and evidence needed for product security: risk assessment, security requirements, testing, vulnerability management, SBOM, documentation and updates.
Threat modeling should be performed for new high-risk features, major architecture changes, new integrations, new data types and changes affecting access or permissions.
At the beginning, tools for secret scanning, dependency scanning, code scanning, configuration scanning and application testing are usually enough, combined with a code review and vulnerability management process. Tools should support the process, not replace risk thinking.
Secure SDLC for SaaS companies and software houses should not be a heavy bureaucratic process. It should be a practical checklist of actions that help build safer products and respond faster to customer, audit and regulatory requirements.
The most important elements are security requirements, threat modeling, secure coding, secrets control, dependency management, SBOM, repository and CI/CD security, security testing, vulnerability management and evidence.
Companies that implement Secure SDLC early reduce technical risk, limit the cost of late fixes and build a sales advantage as more trustworthy software suppliers.
Cyber Resilience Act for Software Houses: What Should Be Prepared in 2026 and 2027?
The Cyber Resilience Act turns digital product cybersecurity from a best practice into a regulatory obligation. Software houses should prepare product risk assessment, secure development lifecycle, vulnerability management, technical documentation, SBOM, update process, incident reporting and a compliance roadmap for 2026 and 2027.
Prepared by: CCyber Editorial Team
A software house should start preparing for the Cyber Resilience Act by checking whether the software it develops is a product with digital elements made available on the EU market and what role the company plays: manufacturer, subcontractor, component provider or service provider. In 2026, the key priorities are vulnerability handling and reporting processes, product cybersecurity risk assessment, secure software development lifecycle, technical documentation, SBOM, update rules and a compliance plan before the main CRA obligations apply in 2027.
July 2026
The Cyber Resilience Act, or CRA, is an EU regulation introducing cybersecurity requirements for products with digital elements. Its goal is to increase the security of products available on the EU market and ensure that vulnerabilities are handled throughout the product support period.
In practice, CRA means that cybersecurity of a digital product cannot be added at the end of the project. It must be included in planning, design, development, testing, release, updates, vulnerability handling and user communication.
For software houses, CRA matters because many technology companies no longer sell only “software development services”. They build applications, components, platforms, SaaS products, integrations, libraries, modules, firmware, mobile applications, IoT systems or software made available on the market under their own brand or a customer’s brand.
The key question is not “do we develop software?”, but “do we make a product with digital elements available on the EU market under our own name or trademark?”.
A software house may act in different roles:
If the company only develops software for a customer, and the customer places the product on the market under its own brand, manufacturer obligations may primarily apply to the customer. This does not mean that the software house can ignore CRA. The customer will likely transfer part of the requirements to the supplier through contracts, development processes, documentation, testing, vulnerability handling and security evidence.
CRA covers products with digital elements, meaning software or hardware and related remote data processing solutions, if the product is made available on the EU market and its intended or reasonably foreseeable use includes connection to a device or network.
Examples that may require CRA analysis:
The fact that a company develops software does not automatically mean that CRA applies. Each case should be assessed based on the business model, product availability, company role, product type and customer contracts.
From this date, provisions concerning conformity assessment bodies apply. For a software house, this matters mainly if a product requires the involvement of a notified body or belongs to an important or critical product category.
From this date, reporting obligations apply for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
In practice, the manufacturer should have a process for:
From this date, most CRA requirements will apply. Products covered by CRA will need to meet cybersecurity requirements, undergo the appropriate conformity assessment, have technical documentation, an EU declaration of conformity, CE marking and a defined support period.
A software house should start with a map of products and roles. Without this, it is difficult to determine which obligations apply directly to the company and which will result from customer contracts.
Check:
Evidence to prepare: product register, product owner, company role, market, product type, availability model and initial CRA classification.
CRA requires a risk-based approach. The manufacturer should assess the cybersecurity risks of the product and use the outcome of that assessment in design, development, delivery and maintenance.
The risk assessment should cover:
Evidence to prepare: product risk assessment report and list of security requirements resulting from the assessment.
A software house should organize the development process so that security is part of daily work, not a one-off test before release.
A secure development lifecycle should include:
Evidence to prepare: secure software development process description, procedures, checklists and test results.
CRA strengthens manufacturer obligations for vulnerability handling. The company needs a process to detect, analyze, prioritize, fix and communicate vulnerabilities.
The process should define:
Evidence to prepare: vulnerability management procedure, vulnerability register, remediation status and reporting decisions.
The company should allow customers, security researchers and users to report vulnerabilities in a controlled way. In practice, this means preparing a clear contact channel, handling rules and internal responsibilities.
Prepare:
Evidence to prepare: vulnerability disclosure policy, contact channel, report register and handling metrics.
SBOM, or Software Bill of Materials, helps determine which libraries, packages and components make up the product. It is important for vulnerability management, software supply chain security and rapid response to new vulnerabilities in components.
A software house should know:
Evidence to prepare: product SBOM, SBOM update process and link with vulnerability management.
Technical documentation is one of the most important elements of CRA preparation. It should show that the product meets cybersecurity requirements and that the company can prove it.
Documentation may include:
Evidence to prepare: complete product technical documentation aligned with CRA requirements and ready to be shown to market surveillance authorities.
From 11 September 2026, manufacturers will have to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
The company should have a process that answers:
Evidence to prepare: CRA reporting procedure, roles, note templates, escalation path and reporting register.
In 2027, the company should move from planning to full readiness. The product should have implemented security requirements, an update process, technical documentation and test evidence.
Key readiness elements:
Before placing the product on the market, the manufacturer should perform the appropriate conformity assessment. For many products, self-assessment may be possible, but some important or critical product categories may require a stricter route, including involvement of a notified body.
The software house should check:
For products covered by CRA, the manufacturer should prepare an EU declaration of conformity and affix CE marking if the product meets the requirements. This requires earlier preparation of documentation, testing, risk assessment and evidence of conformity.
CRA does not end on release day. The manufacturer must handle vulnerabilities and updates during the support period. This requires people, process, tools and budget.
In 2027, the company should have ready:
Most obligations apply in 2027, but reporting obligations begin earlier. In addition, preparing processes, documentation and tests can take many months.
CRA has legal consequences, but the challenge is also technical and organizational. Lawyers can help interpret the regulation, but product, technical and security teams must implement processes.
If a software house develops a product for a customer, it must be clear who is responsible for risk assessment, technical documentation, testing, SBOM, vulnerability handling and product conformity.
Modern digital products use many external libraries and components. Without an SBOM, it is difficult to quickly assess whether a new vulnerability affects the product.
If security testing appears only before release, fixing issues is more expensive and harder. Security should be part of the entire product lifecycle.
The product must be maintained after release. Updates, reports, vulnerability monitoring, user communication and documentation are required.
Even if the team follows good practices, it must be able to show them. Lack of documentation, registers and test results weakens readiness for conformity assessment, customer discussions and controls.
A software house develops a SaaS platform for B2B customers. The product includes a web application, API, customer integrations, mobile application and a component installed in the customer environment. Until now, the company focused on features and delivery time, while security was checked mainly through periodic penetration tests.
After an initial CRA analysis, the company discovers that it needs to organize much more than a security test. It needs a product register, risk assessment, threat modeling, SBOM, vulnerability handling process, reporting procedure, technical documentation and update rules.
The biggest change is not buying a new tool. The biggest change is moving from “testing before release” to “security is part of the entire product lifecycle”.
Within 90 days, the company can prepare the foundation: product map, risk assessment, vulnerability reporting process, SBOM for the main product, basic technical documentation and an action plan for 2027.
ccyber.io helps software houses and product companies prepare for the Cyber Resilience Act in a practical, technical and business-focused way. We do not limit the work to regulatory interpretation. We help translate CRA into processes, documentation, testing and evidence.
We can support your organization with:
The best first step is a short CRA readiness workshop. It helps determine which products may be covered by CRA, what role the company plays, what evidence already exists and what actions should be completed before the 2026 and 2027 deadlines.
It may apply. If a software house places a product with digital elements on the EU market under its own brand, it may act as a manufacturer. If it develops a product for a customer, requirements may be transferred contractually by the customer.
It depends on the product model and service delivery. CRA may cover related remote data processing solutions if they are necessary for the function of a product with digital elements. Each SaaS case should be assessed individually.
CRA has a special approach to free and open-source software. Non-commercial open-source distribution is treated differently from a product made available on the market as part of commercial activity. If a company monetizes an open-source product or places it on the market, scope analysis is needed.
The key priority is to prepare the process for reporting actively exploited vulnerabilities and severe incidents affecting product security. The company should define roles, deadlines, reporting channels and decision documentation.
The company should prepare full readiness for the main CRA requirements: product risk assessment, secure development lifecycle, vulnerability handling, technical documentation, conformity assessment, declaration of conformity, CE marking, support period and user information.
CRA increases the importance of component visibility and vulnerability management. In practice, SBOM is one of the most important tools for demonstrating control over components, dependencies and software supply chain risk.
No. Penetration testing is important, but not sufficient. CRA requires an approach covering the full product lifecycle: risk assessment, design, development, testing, documentation, updates, vulnerability handling and post-release support.
The best starting point is product and role mapping, CRA scope analysis, gap assessment and a 2026-2027 action plan. Then the company should organize secure development, vulnerabilities, SBOM and documentation.
The Cyber Resilience Act changes how technology companies should think about product security. Security is no longer only a best practice, sales advantage or requirement from a large customer. It becomes part of conformity, documentation, risk assessment and manufacturer accountability.
Software houses should use 2026 to prepare the foundation: product mapping, vulnerability handling process, risk assessment, secure development lifecycle, SBOM, technical documentation and reporting procedures.
In 2027, the organization should move to full readiness: conformity assessment, evidence of meeting requirements, user information, support period, declaration of conformity and post-release product security maintenance.
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.