A technology company can launch a connected device, generate thousands of sales and still face significant expenses long after the product leaves the factory. Software vulnerabilities need fixing, security updates require development resources, and technical documentation must remain available. As connected products become more complex, cybersecurity is increasingly becoming a long-term business responsibility.
The European Union’s Cyber Resilience Act is bringing these costs into sharper focus. Its new requirements are encouraging manufacturers to reconsider how they design products, manage software dependencies and finance security support throughout the product lifecycle. The shift towards secure-by-design development may require additional investment before a product reaches the market, but it could also reduce certain operational risks later.
For businesses, the challenge is not simply achieving regulatory compliance. It is determining how security expenditure affects product margins, pricing, development schedules and long-term profitability. As Europe moves towards broader cybersecurity requirements in December 2027, companies need to understand whether their existing business models can support the responsibilities attached to connected technology.
Why Cybersecurity Is Becoming a Product Lifecycle Cost
The traditional economics of consumer electronics often concentrate on production and distribution.
A manufacturer develops a product, sources components, assembles devices and sells them through retail or online channels.
Once a unit is sold, the company may continue providing customer service, warranty support or software updates.
However, connected products introduce additional responsibilities that can remain relevant throughout their useful lives.
A smart camera may require security patches for years. A router can remain operational long after its initial sale, while software applications may depend on third-party components that develop new vulnerabilities.
These dependencies create costs that cannot always be predicted when the product is launched.
A vulnerability discovered three years after release may require engineers to investigate affected versions, develop a correction, test compatibility and distribute an update.
If several product generations depend on the same component, the problem can affect multiple development teams simultaneously.
From an accounting perspective, the exact treatment of these expenses depends on the nature of the expenditure and applicable reporting standards.
From a management perspective, however, the economic reality is straightforward.
A product’s financial performance cannot be understood solely through the margin generated at the time of sale.
The company must also consider the resources required to maintain the security of products already in customers’ hands.
That is why secure-by-design is becoming relevant to financial planning, not only software engineering.
How the Cyber Resilience Act Changes Business Responsibilities
The Cyber Resilience Act, formally established through Regulation (EU) 2024/2847, introduces cybersecurity requirements for covered hardware and software products made available on the European Union market.
The legislation addresses product development, vulnerability management, conformity assessment and the information manufacturers provide to users.
Its implementation follows a phased timetable.
Since 11 September 2026, manufacturers have been required to report certain actively exploited vulnerabilities and severe incidents affecting the security of covered products.
The broader product-security requirements will apply from 11 December 2027.
The European Commission confirmed this timetable in its September 2026 announcement.
For manufacturers, this creates two distinct areas of financial preparation.
The first concerns obligations that are already operational, particularly cybersecurity incident and vulnerability reporting.
Companies need appropriate internal processes to identify relevant events, evaluate their severity and submit notifications within the required deadlines.
The second concerns preparing future products for the broader requirements applicable from December 2027.
That preparation may involve changes to development procedures, technical documentation, supplier management and conformity assessment.
Importantly, not every product requires the same compliance process.
The applicable requirements depend on the type of digital product, its cybersecurity relevance and its regulatory classification.
Businesses therefore need to establish which obligations apply before estimating their compliance costs.
The Financial Difference Between Reactive Security and Secure-by-Design
There are different ways to organise cybersecurity expenditure during product development.
A reactive approach places greater emphasis on responding to problems after they are discovered.
Under such a model, a company might introduce security improvements only when a vulnerability becomes publicly known, a customer reports an issue or an incident exposes weaknesses in the product.
This approach may appear less expensive during early development because fewer resources are allocated to preventive security activities.
However, the apparent savings can be misleading.
Fixing a vulnerability after release may require investigation across multiple versions, emergency engineering work, new testing and communication with existing customers.
If the issue affects a widely distributed product, coordinating the correction can become operationally complicated.
A secure-by-design approach attempts to address relevant risks earlier.
It may involve security reviews during planning, stronger development controls, appropriate testing and more systematic management of software components.
These measures introduce upfront costs.
However, they can also make security-related problems easier to identify and manage throughout the product’s life.
The financial comparison is therefore not simply between spending money on security and spending nothing.
It is between different distributions of cost and risk over time.
A company investing more during development may avoid certain expensive corrections later.
Yet the size of any savings depends on the product, the effectiveness of its controls and the incidents that actually occur.
Secure-by-design does not guarantee that vulnerabilities will disappear.
Its potential economic value comes from reducing avoidable weaknesses and improving the efficiency of the processes used to manage them.
What Does Secure-by-Design Actually Cost a Business?
The cost of introducing stronger product-security processes can vary substantially.
A small software company with a limited number of products faces a different situation from a global electronics manufacturer operating several hardware platforms.
Nevertheless, certain categories of expenditure appear repeatedly.
The first is engineering.
Security requirements may affect software architecture, authentication systems, network interfaces and the management of sensitive information.
Developers need sufficient time and expertise to implement appropriate controls.
Testing creates another expense.
Depending on the product, security verification may involve automated scanning, code analysis, integration testing, independent assessments or specialist penetration testing.
Documentation also requires resources.
Manufacturers must be able to demonstrate how relevant cybersecurity risks were assessed and how the product meets applicable requirements.
That work involves collecting evidence, maintaining technical records and coordinating different teams.
Finally, manufacturers must consider the ongoing processes needed to handle vulnerabilities after release.
A company may need procedures for receiving external reports, evaluating vulnerabilities, preparing corrections and informing relevant parties.
The European Commission’s guidance for manufacturers identifies risk assessment, conformity assessment, technical documentation and vulnerability handling as important parts of the regulatory framework.
These activities create different types of expenditure.
Some represent relatively fixed investments that can potentially be reused across several product lines.
Others vary with the number of products, software versions, dependencies or security incidents.
Understanding that distinction is essential when constructing a realistic business case.
Compliance Costs Are Not the Same for Every Digital Product
A common misunderstanding is that the Cyber Resilience Act will require every software developer or hardware company to purchase the same expensive third-party certification.
That is not how the framework operates.
According to the European Commission’s conformity assessment guidance, many ordinary products can use a manufacturer’s internal conformity assessment procedure.
Examples include certain mobile applications, computer games and consumer electronics.
Other products are subject to stricter processes because their cybersecurity functions or characteristics place them in categories identified as important or critical.
For some important products, using applicable harmonised standards can affect whether self-assessment is available.
Other categories require assessment by a notified body or may use an applicable European cybersecurity certification scheme where the legal conditions permit.
These differences have direct financial implications.
A manufacturer able to use internal conformity assessment may face costs related primarily to engineering, documentation, testing and internal compliance management.
Another manufacturer may also need to pay fees associated with external assessment.
The timing of assessments can influence product schedules.
If conformity procedures reveal weaknesses late in development, correcting those issues may delay market entry.
A delayed product launch can have consequences beyond the direct cost of compliance.
It may affect expected revenue, marketing expenditure, inventory planning and contractual commitments.
This makes early classification and compliance planning commercially important.
The objective should be to identify the correct process before development reaches a stage where substantial changes become expensive.
The Economics of Security Support: Why a Sale Can Create Years of Obligations
One of the CRA’s most significant business implications concerns the period during which manufacturers must handle product vulnerabilities.
Under the regulation’s general framework, the security support period must reflect the time a product is reasonably expected to remain in use.
The support period is generally at least five years.
Where the expected useful life is shorter, a shorter period may be appropriate. Products reasonably expected to remain in use longer may require extended support.
The precise requirements depend on the product and the relevant legal provisions.
This introduces an important consideration for manufacturers.
The support period affects the amount of time during which resources may be needed for monitoring vulnerabilities, developing security updates and maintaining appropriate support processes.
A company selling a router intended for long-term use must consider how it will manage vulnerabilities several years after the initial purchase.
A developer distributing software through an app store faces a different operating environment, but still needs to understand the applicable support obligations.
The financial challenge becomes particularly visible when the product is sold through a one-time payment.
Revenue may be collected at launch, while security-related expenditure continues during subsequent years.
Without appropriate planning, the company can find itself maintaining products that generate limited additional income.
That does not automatically make the business unprofitable.
Security expenses may be shared across several product generations, supported through other revenues or included in the original pricing structure.
Nevertheless, the support obligation must be financially recognised.
Selling a digital product can create a continuing responsibility that extends well beyond the original customer transaction.
A Hypothetical Example: How Security Costs Affect Product Margins
Consider a hypothetical company preparing to sell a connected device in the European market.
For simplicity, assume that the company estimates the following additional cybersecurity-related expenditure for a particular product programme:
Cost category | Hypothetical cost |
Initial security engineering and preparation | €120,000 |
Conformity assessment and associated documentation | €30,000 |
Annual security maintenance and vulnerability handling | €60,000 |
Assumed support period | 5 years |
The projected five-year security-related expenditure would be:
€120,000 + €30,000 + (€60,000 × 5) = €450,000
How significantly does this affect unit economics?
That depends partly on how many units the business sells.
Units sold | Allocated security cost per unit |
5,000 | €90 |
10,000 | €45 |
20,000 | €22.50 |
30,000 | €15 |
All figures are hypothetical and illustrative. They are not estimates published by the European Commission and do not represent standard CRA compliance costs. The calculation excludes financing effects, other operating costs and the possibility of additional security expenditure.
The example highlights an important characteristic of product economics.
Some development and compliance expenses can be spread across the number of units sold.
When sales volume increases, the allocated cost per unit declines, assuming total expenditure remains unchanged.
However, that assumption will not always hold.
More customers, supported versions or connected devices may increase infrastructure and support requirements.
A larger installed base can also increase the operational impact of a vulnerability.
The allocation is therefore useful as a simplified planning tool, not as a complete profitability forecast.
The key lesson is that cybersecurity needs to be included in product economics before a company establishes its pricing and expected margin.
The Scale Advantage: Can Larger Manufacturers Absorb These Costs More Easily?
Larger technology companies often possess resources that smaller competitors cannot easily replicate.
They may maintain established security teams, internal compliance processes, automated testing systems and long-term relationships with specialist suppliers.
Those capabilities can support several product lines simultaneously.
A security process developed for one product family may be adapted for another, reducing the need to recreate every procedure from the beginning.
Smaller manufacturers may face a different challenge.
A startup developing its first connected device might need external support to conduct an appropriate risk assessment or prepare technical documentation.
The business may also have limited staff available to investigate vulnerabilities while continuing ordinary product development.
This creates the possibility of a disproportionate fixed-cost burden.
The same type of compliance infrastructure can represent a relatively modest expense for a large company but a major investment for a small business.
Nevertheless, scale does not eliminate complexity.
Large manufacturers may operate numerous product generations, different hardware architectures and extensive software supply chains.
Maintaining security across such an environment introduces its own coordination expenses.
The economic advantage is therefore not simply company size.
It is also the ability to standardise processes, reuse infrastructure and manage product portfolios efficiently.
Why the European Commission Is Paying Special Attention to SMEs
The European Commission has explicitly recognised the implementation challenges facing microenterprises and small and medium-sized enterprises.
In July 2026, it published additional guidance intended to help businesses understand the CRA’s scope, support periods, reporting obligations and risk assessment requirements.
The guidance also addresses practical questions raised by smaller companies.
According to the Commission’s official announcement, the objective is to reduce unnecessary administrative burdens while supporting timely implementation.
The legislation also provides for measures that can assist smaller manufacturers.
These may include targeted training, technical information, testing support and regulatory sandboxes developed through relevant initiatives.
The Commission’s SME guidance page also identifies EU-supported projects designed to help companies prepare for the CRA.
Such measures do not mean that small businesses are generally exempt from the legislation.
They reflect the need for proportional implementation and practical assistance.
There are also specific provisions concerning penalties.
For example, microenterprises and small enterprises benefit from an exemption from fines for missing the CRA’s 24-hour early-warning reporting deadline, although this does not eliminate the underlying reporting obligation or other applicable responsibilities.
From a business perspective, these distinctions matter.
A small company should not assume that compliance is optional.
Equally, it should not assume that every product requires the most expensive possible assessment procedure.
A reliable estimate starts with understanding the company’s actual obligations.
Software Supply Chains: The Hidden Cost of Third-Party Dependencies
Modern digital products rarely consist entirely of software developed internally.
Manufacturers frequently incorporate operating systems, libraries, software frameworks and other components created by external organisations.
Open-source software is particularly important in this environment.
These dependencies can reduce development time and allow companies to build products using mature technologies.
However, they also create security responsibilities.
If a widely used library contains a vulnerability, every product that incorporates an affected version may require investigation.
The manufacturer needs to identify whether the component is present, determine whether the vulnerability affects the product and decide what corrective action is necessary.
This creates a business case for maintaining accurate information about software dependencies.
The CRA’s vulnerability-handling framework includes requirements relating to identifying and documenting product components, including through a software bill of materials, commonly known as an SBOM.
An SBOM helps organisations maintain structured information about the software components incorporated into a product.
It is not a guarantee of security.
Its value lies in improving visibility.
When a vulnerability is discovered, a manufacturer with reliable component records may be better positioned to identify affected products.
A company that cannot determine which components are used across its product portfolio may spend additional time investigating each product individually.
That difference can affect engineering efficiency and incident response costs.
Ericsson Software Technology: A Real Example of Reducing Security Maintenance Complexity
An interesting business example comes from Ericsson Software Technology and its work with open-source projects.
In August 2026, the Open Source Security Foundation published a case study examining how Ericsson Software Technology approached software supply-chain security in preparation for CRA-related responsibilities.
According to the case study, the team moved away from maintaining private software forks and invested more heavily in collaboration with upstream open-source projects.
Its reported activities included:
- 214 direct security-related pull requests.
- More than 1,400 merged dependency-update pull requests.
- Eliminating the need to maintain private forks within the initiative described.
The distinction between private patches and upstream collaboration is economically significant.
When a company maintains its own modified version of an open-source component, it may need to reconcile future updates with those modifications.
That can create repeated maintenance work.
Contributing improvements to the original project can reduce the need to maintain separate versions, provided those contributions are accepted and integrated.
The benefits can extend beyond one company’s products because other users of the component can also access the improvements.
The case study provides a practical example of how supply-chain security and engineering cost control can support one another.
However, it does not establish a general financial return that can be applied to every manufacturer.
The published results describe a particular engineering initiative rather than an independently calculated industry-wide saving.
It would therefore be inaccurate to claim that every company could achieve the same reduction in maintenance costs.
The broader business principle is nevertheless relevant.
Reducing unnecessary software fragmentation can make long-term security support easier to manage.
Why Vulnerability Reporting Is Already a Business Cost in 2026
While many of the CRA’s product requirements will apply from December 2027, certain reporting obligations have been operational since September 2026.
Manufacturers must report actively exploited vulnerabilities and severe security incidents meeting the relevant criteria.
An early warning is required within 24 hours of awareness, followed by a notification within 72 hours.
Additional final-report deadlines depend on the event.
The European Commission’s reporting guidance explains the requirements and the role of the Single Reporting Platform maintained by ENISA.
For businesses, these deadlines have operational consequences.
An organisation needs to determine whether a reported issue meets the relevant criteria.
It must identify responsible personnel, establish internal escalation procedures and ensure that the information required for reporting can be collected promptly.
These processes may involve security engineers, legal advisers, compliance specialists and senior management.
The need for timely coordination becomes particularly relevant when a vulnerability affects several products or business units.
A company without a defined response process may experience delays while determining who is responsible for investigating and reporting the issue.
This does not mean that every routine software bug creates an automatic CRA reporting obligation.
The requirements concern specific categories of actively exploited vulnerabilities and severe incidents.
The economic challenge is to build a process capable of distinguishing reportable events from other technical problems without unnecessary operational disruption.
Importers, Distributors and Private-Label Brands Also Face Business Implications
The Cyber Resilience Act is not relevant only to companies developing software or manufacturing electronics.
The regulation also introduces responsibilities for economic operators involved in bringing covered products to the EU market.
Importers need to verify relevant aspects of product conformity and ensure that manufacturers have fulfilled applicable obligations.
Distributors must also perform appropriate checks before making products available.
This matters for companies that import connected devices from manufacturers based outside the European Union.
A European business selling smart cameras, routers or other connected products may need information about conformity assessment, CE marking, documentation and security support.
The precise obligations depend on its role in the supply chain.
The situation becomes more significant when a business markets a product under its own name or trademark.
Under the CRA, the legal definition of a manufacturer can include a company that has products developed or manufactured by others and markets them under its own brand.
Consequently, outsourcing production does not necessarily remove manufacturer-level responsibilities.
For a private-label technology business, that distinction can have considerable financial implications.
The company may control branding and distribution while relying on external suppliers for firmware development and technical maintenance.
If the commercial model does not provide reliable access to security updates or vulnerability information, the brand owner may face difficulties fulfilling its own obligations.
Supplier contracts therefore become an important part of financial and compliance planning.
The Contractual Cost of Cybersecurity in Global Supply Chains
Connected devices often involve international supply chains.
A company may source hardware from one country, license firmware from another supplier and use cloud infrastructure provided by a third organisation.
The resulting product can appear under a single brand, even though several businesses contribute to its functionality.
This creates a coordination challenge.
Who will investigate vulnerabilities in a third-party component?
Who is responsible for developing firmware corrections?
How quickly must suppliers provide the information required for incident reporting?
What happens if a critical software component is no longer maintained?
These questions can influence both commercial contracts and product development decisions.
A manufacturer may seek clearer commitments from suppliers concerning security updates, access to vulnerability information and cooperation during incidents.
Such arrangements can reduce uncertainty, but they may also affect procurement costs.
A supplier offering stronger long-term maintenance commitments may charge more than one providing only the initial component or software package.
Businesses therefore need to compare the immediate procurement price with the broader cost of maintaining a compliant and secure product.
The lowest-cost component is not necessarily the lowest-cost option over the full product lifecycle.
However, higher supplier prices do not automatically guarantee better security.
The commercial value depends on the actual obligations, capabilities and reliability of the supplier.
Could the Cyber Resilience Act Affect Product Prices?
Additional development and compliance expenses can influence pricing decisions.
A company facing higher expected product costs may attempt to recover those expenses through its selling price.
However, whether this is commercially possible depends on competition, customer demand and the product’s market position.
A manufacturer cannot simply assume that buyers will accept any price increase.
In highly competitive markets, businesses may need to absorb some additional costs through lower margins.
Other companies may reduce expenditure elsewhere, simplify product portfolios or improve operational efficiency.
Some may decide to serve fewer product categories if maintaining a large portfolio becomes too expensive.
Conversely, firms with efficient security processes may be able to distribute compliance expenditure across several product lines.
That can create a cost advantage compared with competitors that repeatedly develop similar processes independently.
The CRA therefore introduces potential effects on both prices and competitive strategy.
It does not, however, provide a basis for predicting a uniform price increase across all connected devices.
The financial effect will differ considerably between a low-cost connected accessory, a premium smartphone and specialised industrial software.
Compliance Risk: What Financial Penalties Could Businesses Face?
The Cyber Resilience Act establishes a framework for administrative penalties associated with specific infringements.
Under Article 64, breaches of the essential cybersecurity requirements and certain manufacturer obligations can be subject to fines of up to €15 million or 2.5% of the undertaking’s total worldwide annual turnover, whichever is higher.
Other categories of infringement are subject to different ceilings.
These are statutory maximum amounts, not automatic fines imposed whenever a vulnerability is discovered.
The application of penalties depends on the relevant legal conditions, enforcement decisions and the circumstances of the infringement.
The regulation also includes proportionality considerations and specific treatment for certain smaller enterprises.
The possible consequences of non-compliance are not limited to financial penalties.
Depending on the circumstances, market surveillance authorities may require corrective action or impose restrictions affecting the availability of a non-compliant product.
For businesses, this introduces a wider category of regulatory and operational risk.
A delayed product launch, interruption to sales or required correction can affect revenue and cash flow even without the maximum financial penalty being imposed.
However, it would be misleading to use the largest possible fine as though it represented the expected cost of non-compliance.
A responsible financial assessment needs to distinguish between legal exposure and the probability and financial impact of specific scenarios.
Can Secure-by-Design Create a Competitive Advantage?
Security expenditure is frequently viewed through the lens of cost prevention.
A company invests in appropriate controls to reduce the likelihood or consequences of security incidents.
That is a legitimate business objective.
However, secure-by-design may also influence commercial opportunities.
A manufacturer with established security processes may find it easier to prepare documentation, respond to enterprise procurement requirements or demonstrate conformity with applicable product standards.
For organisations selling technology to businesses, such capabilities may support participation in procurement processes where cybersecurity documentation is an important consideration.
Companies may also benefit operationally from reusing tested software components and established vulnerability-handling procedures.
Nevertheless, these potential advantages should not be presented as guaranteed financial returns.
There is no universal formula demonstrating that a given investment in product security will produce a specific increase in sales or profitability.
The economic value depends on the product category, buyer requirements, competitive environment and effectiveness of the organisation’s security processes.
For some manufacturers, the strongest financial argument may be avoiding costly disruptions.
For others, improved engineering efficiency or access to certain markets may be more significant.
The correct approach is to assess the actual mechanisms through which security investment can create measurable value.
The Business Case for Reusable Security Infrastructure
One possible way to manage growing compliance requirements is to avoid treating every product as a completely independent project.
A manufacturer producing several connected devices may be able to use shared security policies, update infrastructure and vulnerability-management procedures.
For example, a company operating multiple smart home product lines could develop common processes for receiving vulnerability reports and distributing security advisories.
Individual products would still need appropriate assessment and technical controls.
However, some organisational activities could be managed through shared systems.
This can reduce unnecessary duplication.
The same principle applies to technical documentation and supplier management, provided the company maintains the product-specific evidence required for compliance.
Reusable infrastructure introduces its own initial investment.
The company needs to develop processes, maintain tools and assign clear responsibilities.
But as more products are supported, the cost of shared infrastructure can potentially be distributed across a wider portfolio.
This makes product architecture and organisational design relevant to the economics of cybersecurity.
A business that develops security processes only when individual problems arise may struggle to benefit from such efficiencies.
A more coordinated approach can create opportunities for consistency and better cost visibility.
What Businesses Should Budget for Before December 2027
For companies preparing for the CRA’s wider implementation, the financial planning process should begin with an accurate understanding of the affected products.
A product inventory can help identify which devices, applications and software components are potentially within scope.
The company then needs to determine the applicable regulatory classification and conformity assessment procedure.
This informs the resources required for technical assessment, documentation and external services where necessary.
A realistic budget should also address internal capabilities.
Does the organisation have the expertise to perform cybersecurity risk assessments?
Can existing engineering teams manage vulnerability handling, or will specialist support be required?
Are the relevant software dependencies documented?
Does the company have procedures for meeting the reporting obligations already applicable in 2026?
These questions help translate regulatory requirements into operational expenditure.
The business should then assess support periods and expected product lifetimes.
A longer support commitment may require resources for several years after sales peak.
Financial forecasts should include that continuing responsibility rather than treating support as an uncertain expense to be addressed only when necessary.
The European Commission’s July 2026 implementation guidance can help organisations understand the framework before making costly compliance decisions.
For products where classification or legal obligations remain uncertain, specialist advice may be necessary.
Why Cybersecurity Investment Needs Its Own Financial Strategy
The traditional separation between engineering expenditure and business strategy becomes less useful when a product requires ongoing digital security support.
Security decisions influence development schedules, supplier selection, support costs and potential regulatory exposure.
They may also affect which products a company chooses to develop or continue selling.
For a business with limited resources, maintaining an extensive product portfolio can become financially challenging when each product requires separate technical maintenance.
A narrower portfolio supported through common infrastructure may sometimes offer better economics.
Other manufacturers may invest in modular software architecture to reduce the effort involved in maintaining several device generations.
There is no universally optimal approach.
What matters is that security-related responsibilities are considered alongside ordinary product-development and investment decisions.
This also helps explain the difference between the various perspectives of the Cyber Resilience Act.
Athens Pulse, in “The Cyber Resilience Act: Why Europe Is Changing the Rules for Connected Devices” examines the technological and regulatory developments affecting connected hardware and software.
Targeted.gr, in “Security as a Brand Promise: Why Software Support Is Becoming Part of Customer Trust” explores how ongoing security support influences customer expectations and brand credibility.
For Market Insiders, the central concern is how those same responsibilities affect business economics.
Companies must decide how to allocate resources, manage long-term liabilities, organise their supply chains and maintain commercially sustainable products.
The next article in the cycle, for Techrow.gr, will take a practical consumer-oriented approach in “How to Check a Smart Device’s Security Support Before You Buy It”
That guide will examine how buyers can verify update policies, firmware availability and manufacturer support information.
These different perspectives reveal why product cybersecurity can no longer be examined as an isolated technical function.
It increasingly forms part of how connected technology is financed, marketed and maintained.
The Long-Term Economics of Product Cybersecurity
The Cyber Resilience Act is changing the way businesses must think about the financial responsibilities attached to connected products.
The regulation’s reporting obligations are already operational in 2026, while broader cybersecurity requirements will follow in December 2027.
For manufacturers, preparation involves more than selecting appropriate security tools.
It requires understanding product risks, documenting relevant decisions, maintaining secure development processes and financing vulnerability handling across the expected life of the product.
These requirements can introduce additional costs, particularly for businesses that have not previously maintained formal security processes.
They can also encourage more systematic engineering practices and better visibility into long-term operating expenses.
The economic effects will not be identical across the market.
Larger companies may benefit from scale and shared infrastructure, while smaller businesses may face a greater initial burden. Product categories requiring external conformity assessment can have different cost structures from those eligible for internal procedures.
At the same time, opportunities exist to reduce unnecessary complexity through standardised processes, reliable supplier relationships and better management of open-source dependencies.
For Market Insiders, the main economic question is not whether cybersecurity costs money. Every serious product-development strategy already involves trade-offs between investment, functionality, risk and commercial return.
The more important question is how those costs are distributed across development, production and the years following a sale.
A manufacturer that understands those responsibilities early can make better-informed decisions about pricing, investment and product strategy.
Ultimately, secure-by-design is not simply a new compliance expense. It is a shift in the economics of digital products, where financial sustainability increasingly depends on the ability to maintain security long after the initial sale.
Frequently Asked Questions About Secure-by-Design Economics
What does secure-by-design mean for businesses?
Secure-by-design means incorporating appropriate cybersecurity considerations into the planning, development and maintenance of digital products. From a business perspective, it involves allocating resources to security processes throughout the product lifecycle rather than relying exclusively on corrections after vulnerabilities are discovered.
How does the Cyber Resilience Act affect business costs?
The CRA can create expenditure related to risk assessment, secure development, testing, technical documentation, conformity assessment, vulnerability management and ongoing product support. The actual cost varies depending on the product, the manufacturer’s capabilities and the applicable regulatory requirements.
When do the Cyber Resilience Act’s business obligations apply?
Mandatory reporting obligations for specified actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. The main product cybersecurity requirements will apply from 11 December 2027, with other provisions following their specific implementation timelines.
Does every technology company need expensive third-party certification?
No. Many covered products can use internal conformity assessment. Some important or critical product categories face stricter procedures that may require assessment by a notified body or an applicable certification scheme. The correct procedure depends on the product’s classification and the relevant requirements.
Why does long-term software support affect profitability?
Security maintenance can continue long after the original sale. Companies may need to finance vulnerability investigation, software updates, testing and related operational processes throughout the product’s support period. These costs can affect margins, pricing and the economics of maintaining older products.
Are small businesses exempt from the Cyber Resilience Act?
No, there is no general exemption for small businesses. However, the legislation includes measures intended to support microenterprises and SMEs, including proportionality considerations and certain specific provisions concerning administrative penalties.
Does the Cyber Resilience Act require at least five years of security support?
The general minimum support period is five years, but a shorter period may apply where the product’s reasonably expected useful life is shorter. Products expected to remain in use for longer may require a longer support period. The applicable requirements must be assessed for the particular product.
Can open-source software reduce CRA compliance costs?
Open-source software can reduce certain development costs, but it does not automatically eliminate security responsibilities. Effective dependency management and upstream collaboration may help businesses reduce maintenance complexity. The financial outcome depends on the product, software architecture and organisation.
What is an SBOM and why does it matter financially?
A software bill of materials documents components incorporated into a software product. It can help manufacturers identify affected products when vulnerabilities are discovered. Better component visibility may reduce the time and effort required for certain investigations, although maintaining accurate records also involves costs.
What financial penalties does the Cyber Resilience Act establish?
Certain infringements can attract administrative fines of up to €15 million or 2.5% of a company’s worldwide annual turnover, whichever is higher. These are maximum statutory ceilings for specified breaches, not automatic penalties for every vulnerability. Different provisions and proportionality considerations apply depending on the circumstances.
Can secure-by-design become a competitive advantage?
Potentially. Established security processes may support product reliability, operational efficiency and access to customers with cybersecurity requirements. However, security investment does not guarantee higher sales or profitability. Its value depends on implementation, market conditions and the product’s business model.