Cyber Resilience Act: Should You Build or Buy Software Licensing?
Over the last few months, a pattern has shown up in the concerns of software and device manufacturers. When they explain why they're finally moving off a homegrown licensing system, the EU Cyber Resilience Act (CRA) keeps coming up. It's rarely the only reason, but it's often the one that tipped the decision.
The CRA's first obligations, mandatory reporting of actively exploited vulnerabilities and severe incidents, started on 11 September 2026. The full set of product, lifecycle and conformity obligations applies from 11 December 2027. That timeline puts licensing on the table, because your licensing code ships inside your product, so it sits inside your CRA scope.
Below, I cover what the CRA asks of manufacturers, why the licensing layer is in scope, what building it in-house costs now, and what to expect from a licensing vendor instead.
What the Cyber Resilience Act Asks of Software Manufacturers
The Cyber Resilience Act (Regulation (EU) 2024/2847) sets mandatory cybersecurity requirements for "products with digital elements" made available on the EU market. That covers hardware and software, including software supplied on its own and the remote data processing a product needs to function. It applies to manufacturers outside the EU too, as long as they sell into it.
The obligations that matter most for software teams:
- •
Secure by designProducts must be designed, built and shipped with cybersecurity risk assessed and addressed, including secure default configurations.
- •
Vulnerability handlingManufacturers need a process to identify, fix and disclose vulnerabilities, including a coordinated vulnerability disclosure policy.
- •
Security updates for a declared support periodThe support period must generally be at least five years, and each security update must stay available for at least ten years after it's issued.
- •
A software bill of materials (SBOM)A machine-readable SBOM covering at least top-level dependencies must be part of the technical documentation.
- •
ReportingActively exploited vulnerabilities and severe incidents must be reported, with an early warning within 24 hours of becoming aware and a fuller notification within 72 hours. The European Commission sets out the details in its CRA reporting obligations guidance.
- •
Conformity and CE markingProducts need technical documentation, a conformity assessment and CE marking before they can be placed on the market.
Breaches of the essential requirements can bring fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.
Why Your Licensing Layer Is in Scope
Most teams think of licensing as a commercial concern: who has paid for what. Under the CRA, it's also a component. Your licensing SDK is compiled into your application. Your local license server gets installed on customer networks. Your activation service and customer portal are part of how the product works.
The CRA is also explicit that manufacturers are responsible for the components they integrate, not only the code they write. If you use third-party components, you need to exercise due diligence to make sure they don't compromise the security of your product. That applies whether you built the component or bought it.
And licensing isn't a low-risk component. It handles cryptographic keys, activation, authentication and the switch that turns product functionality on or off. It's exactly the kind of code attackers probe, and exactly the kind of code that tends to be written once, by one or two engineers, and then left alone for years.
The Real Cost of Building Licensing Under the Cyber Resilience Act
Before the CRA, the cost of a homegrown licensing system was mostly engineering time: building it, then maintaining it as pricing models and deployment targets changed. We've written about that real cost of building and maintaining a licensing platform before. The CRA adds a compliance workload on top, for every product, for the whole support period.
| CRA obligation | If you build licensing in-house | If you buy from a specialist vendor |
|---|---|---|
| SBOM | You generate and maintain SBOMs for your licensing code and every library it depends on | The vendor supplies SBOMs for its SDKs and components, which you fold into yours |
| Vulnerability handling | You monitor, triage and fix vulnerabilities in your own licensing code | A dedicated team handles it across every customer, with a published disclosure process |
| Secure updates | You build and secure signed update delivery for licensing components | Signed, versioned releases come from a vendor whose core job is this code |
| Five-year support period | You fund licensing security work for at least five years per product, after the original authors may have left | Support and update commitments are part of the vendor relationship |
| 24-hour reporting | You need to identify affected versions and customers fast enough to warn authorities within 24 hours | The vendor cooperates on investigation, and entitlement records show who runs what |
| Technical documentation | You document design, risks and testing for a component nobody wants to own | The vendor provides security documentation and assurance evidence |
| Offline and air-gapped sites | You solve update delivery and vulnerability notices for disconnected customers yourself | Offline activation and entitlement workflows are already built and supported |
You can do all of this yourself. Every item, though, comes out of the same security budget and the same engineers as your core product.
Where In-House Licensing Breaks First
Teams preparing for the CRA keep hitting the same weak points. If any of these sound familiar, your licensing system is likely to become a CRA problem before your core product does.
Knowledge sits with one or two people
The licensing code works, but only its original authors fully understand it. Documenting it to CRA standards, or patching it quickly, depends on people who may have moved on.
Every product has its own implementation
Acquisitions and years of product launches leave a patchwork of licensing systems. Each one needs its own SBOM, its own vulnerability process and its own evidence.
You can't quickly see who is affected
When a vulnerability hits a specific version, you need to know which customers and deployments run it. Without a central entitlement record, that answer takes days, not hours.
Offline customers are hard to reach
Industrial, defense and regulated customers often run disconnected or air-gapped. Getting security updates and notices to them needs a deliberate process.
CRA work competes with the roadmap
Every hour spent bringing a homegrown licensing system up to CRA standards is an hour not spent on the product your customers actually pay for.
What Buying Does, and Doesn't, Do for CRA Readiness
Buying a licensing platform doesn't make your product CRA compliant. Nothing you buy does. Compliance is a property of your product and your processes, and you remain the manufacturer.
Buying moves a security-sensitive component off your plate and onto a vendor whose whole business is maintaining it. Instead of building SBOMs, disclosure processes, signed updates and a five-year support plan for licensing yourself, you get them from a specialist, and your team focuses its CRA effort on your own product.
It also gives you a single, auditable record of which customers are entitled to which products, features and versions, across every deployment. Homegrown systems rarely have one. When a vulnerability needs a response inside a 24-hour window, that record tells you which customers to contact.
If you're weighing the wider business case, our build vs. buy guide for software licensing covers the cost, time-to-market and focus arguments that sit alongside the CRA.
What to Ask a Licensing Vendor About the EU Cyber Resilience Act
Because a licensing vendor becomes part of your supply chain, expect to run due diligence on them, and expect them to welcome it. These are the questions we'd ask:
- •
ScopeWhich SDKs, agents, local servers and services ship inside or alongside my product?
- •
Vulnerability disclosureDo you have a coordinated vulnerability disclosure policy and a clear security contact?
- •
Support periodsWhat security update commitments cover the components I ship, and for how long?
- •
Secure updatesHow are releases signed and distributed, including for offline and air-gapped deployments?
- •
Incident cooperationIf your component contributes to a reportable vulnerability, how fast will you work with us?
- •
Assurance evidenceWhat independent evidence of your security practices can you share, such as SOC 2 Type II reports and penetration testing?
A vendor that can't answer these clearly is handing the problem back to you.
Vendor due diligence gets the closest scrutiny in regulated industries and for industrial manufacturers, where the CRA sits alongside existing sector rules.
Built for the CRA Era: How Nalpeiron Supports You
At Nalpeiron we're building Cyber Resilience Act readiness directly into Zentitle and Zenmeter, because our customers shouldn't have to carry the security and compliance burden of their licensing layer alone. Licensing, entitlements and metering are all we do, so this is our job, not a side project competing with your roadmap.
That work builds on foundations already in place. Nalpeiron is SOC 2 Type II compliant, and we're extending the same discipline to CRA readiness across our SDKs, local license server and metering agents.
Zentitle is where the CRA bites hardest, because its components ship inside your products: the SDKs, the local license server for on-premise and air-gapped sites, and the activation and entitlement services behind them. One platform across your whole portfolio means one set of components to assess instead of a different homegrown system per product.
Zenmeter is part of the same supply chain. Usage metering agents and the usage data they send are part of how your product works, so we hold Zenmeter to the same standard.
If the EU Cyber Resilience Act (CRA) is shaping your licensing decisions, talk to us now. We'll map your requirements to our roadmap so your licensing stack is ready when you are.
Frequently Asked Questions
Does the Cyber Resilience Act apply to software licensing systems?
In most cases, yes. The CRA covers products with digital elements, including the components integrated into them. A licensing SDK compiled into your application, or a license server installed on customer sites, is part of the product, so it falls under your CRA obligations whether you built it or bought it. Confirm the exact scope for your products with qualified counsel.
Does buying a licensing platform make my product CRA compliant?
No. CRA compliance applies to your product and your processes, and you remain the manufacturer. Buying from a specialist vendor moves the work of maintaining a security-sensitive component, including SBOMs, vulnerability handling and security updates, to a team that does it full time, so your own CRA effort can focus on your product.
When does the Cyber Resilience Act take effect?
The CRA entered into force in December 2024. Mandatory reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, including for products already on the market. The main product, lifecycle and conformity obligations apply from 11 December 2027.
Is a local license server covered by the Cyber Resilience Act?
A license server you distribute for customers to install on their own networks is software supplied as part of, or alongside, your product, so it's generally treated as in scope. That means it needs the same vulnerability handling, security updates and documentation as the rest of your product for the declared support period.
What should I ask my licensing vendor about the CRA?
Ask which of their components ship in your product, whether they provide machine-readable SBOMs per version, what their coordinated vulnerability disclosure policy is, what security update commitments cover their components, how releases are signed and delivered (including offline), how they'll cooperate on reportable incidents, and what assurance evidence, such as SOC 2 Type II reports, they can share.
About the Author
Jon Gillespie-Brown is the Founder and CEO of Nalpeiron, a leader in cloud-based software licensing, entitlement management, software monetization, and analytics. With over 20 years of expertise, he works with enterprise B2B SaaS and IoT companies to optimize revenue models, accelerate go-to-market strategies, and scale with confidence. Jon is recognized as an authority in software licensing, software monetization, and software analytics, holds two issued U.S. patents, and is the author of five books. He also serves as a strategic guide to customers, helping them navigate and capitalize on the once-in-a-generation shift driven by AI, redefining how software is built, delivered, and monetized. For over 20 years, Jon has been a Professor at University of Colorado Boulder, a lecturer at University of California, Berkeley and Stanford University, and an Entrepreneur in Residence at London Business School.
Nalpeiron: A Long-Term Partner for the AI Era
At Nalpeiron, we go beyond technology — we act as a strategic partner in licensing, monetization, and growth. For over twenty years, enterprise and IoT companies have trusted us to guide and evolve their business models.
As AI shifts software from seats to usage, outcomes, and agent-driven activity, legacy approaches fall short. Nalpeiron enables this transition through entitlements as the control plane — a centralized system of record across SaaS, on-prem, IoT, and offline environments.
From strategy to execution, we help companies adapt faster, launch new models, and stay in control — making Nalpeiron a partner for the AI-driven future of software monetization.
Ready to Optimize Your Strategy?
See how Nalpeiron helps companies implement flexible monetization strategies that support both product-led and sales-led growth motions.
Book a Demo