The Cyber Resilience Act for Indie Software Sellers

For software developers, the Cyber Resilience Act raises a practical licensing question: can a customer receive a security fix after their paid feature-upgrade period ends? Start by separating permission to run a release, access to new features and your security-support policy. A single “updates until” date cannot explain all three.

Checked 31 October 2026. This is general information and an engineering planning guide, not legal advice, a complete CRA checklist, certification or a claim that PermitCore makes your product compliant. Have the product's scope, transition rules and contractual wording reviewed by a qualified adviser.

Check the product's scope before changing checkout

The Commission's summary describes products supplied commercially on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Specific exclusions exist. “Desktop app”, “plugin” and “game tool” are useful engineering labels, not scope determinations.

Write down what you distribute, its connections, dependencies and remote functions, where it is offered and which organisation markets it. A plugin's host application and an app's supporting service deserve explicit review. Do not assume that every SaaS service is covered, or that an offline-capable app is excluded.

Being small is not a blanket exemption: the Commission describes support measures for micro and small businesses, including guidance and possible simplified documentation. For open source, commercial activity and the manufacturer's role matter; non-commercial development and software stewards have different treatment. A free price or public repository alone does not settle the question.

The reporting date has already passed

The Commission's timeline puts the main obligations at 11 December 2027, while manufacturer reporting under Article 14 applies from 11 September 2026. At this article's publication, reporting is already in force.

The reporting guidance covers actively exploited vulnerabilities and severe product-security incidents. It describes an early warning within 24 hours of awareness and notification within 72 hours. Final reports have different clocks: 14 days after a corrective measure becomes available for an actively exploited vulnerability; one month after the 72-hour notification for a severe incident. The Single Reporting Platform is operational. Software stewards' Article 24 reporting starts in December 2027.

Build a real incident workflow: who assesses a report, who can submit it, who covers absence and where evidence is retained. A failed license check or suspicious activation is not automatically a reportable CRA incident. PermitCore webhooks do not submit regulatory reports for you.

For older products, Article 69 generally brings pre-December-2027 products under the main requirements when substantially modified after that date; Article 14 reporting still reaches older in-scope products. Read the Regulation's transition provisions before treating an existing release as grandfathered.

Support length is separate from license length

Article 13(8) ties support to expected use and reasonable user expectations. It normally requires at least five years; genuinely shorter expected use means that duration. Longer expected use can require longer support. Document the rationale. Article 13(9) keeps each issued security update available for ten years after issue or the remaining support period, whichever is longer. That is not ten years of new patches.

Article 13(10)'s latest-version route has conditions: earlier users get that version free and incur no extra hardware or software-environment adjustment costs. It is not permission to require a paid upgrade for a fix. See Article 13.

The Commission summary also explains that the support end date, including month and year, must be clear at purchase. Plan how customers will find that date again in their account, release notes or app. Do not let an automatic subscription renewal silently rewrite an older purchase's documented policy.

Separate security fixes from paid feature upgrades

Annex I, Part II(8) requires security updates without delay and free of charge, except where otherwise agreed with a business user for a tailor-made product. This is not a general B2B exception. Read the Annex with your adviser.

As an engineering design, keep a supported security-release path independent of the upsell gate. A perpetual customer whose feature-upgrade period ended should see a useful explanation and the applicable security channel, rather than a generic “renew to download anything” screen. A security release can preserve the purchased feature set. Test the actual installer and download permissions, not just the wording on your pricing page.

This is a policy layout, not sample legal terms or a universal five-year promise. Fill it from your assessed product lifecycle. See the perpetual versus subscription guide for commercial distinctions; those distinctions do not themselves determine statutory support.

Know what version information you actually have

Keep a release inventory in your build pipeline: version, release date, dependency manifest, signed installer, security changes and support family. Separately track the minimum customer information needed to communicate a fix. Avoid turning licensing into unnecessary surveillance.

PermitCore can receive an application version when your client supplies one. Activation history and validation records are observations, not a complete installed-base inventory: an offline installation or a client that never reports its version is invisible to that process. Do not infer that every customer installed a patch because the download was authorised.

Use a public security-advisory page and an appropriate direct notification process alongside account messages. Test the contact route without exposing a vulnerability prematurely or putting customer license keys in emails and logs. Your release and incident procedures still need their own owners.

Use licensing controls without confusing them with patch delivery

PermitCore's maintenance period, version bounds and custom fields can express parts of an application entitlement policy. They do not create an update server. If your download service treats expired maintenance as a universal denial, you must implement a separate, authorised security-update path. Review the actual validation response and your application's handling of it; do not assume a metadata field changes server-side access rules.

PermitCore does not build or distribute your security patches, sign your installers, generate your product's SBOM, perform its conformity assessment, notify every offline installation or report to ENISA on your behalf. The manufacturer guidance describes the wider work, including risk assessment, technical documentation and conformity procedures. Buying a licensing service does not complete it.

A Merchant of Record handles its agreed payment role. Do not assume that changing checkout transfers the software manufacturer's security duties. Identify each party's role and review the contract. This article changes no Stripe or Paddle configuration.

Plan end of support without unexpectedly disabling paid copies

Decide what happens to execution, online checks, downloads and customer records separately. If an app promises perpetual use, a support notice should not accidentally become a kill switch. See license rights and ownership and the license-server exit plan.

Signed offline proofs can reduce dependence on a live server, within their actual signature, device and expiry checks. They do not become valid forever when support ends, override revocation already known online or renew a floating lease. Test offline grace and a restored self-hosted deployment before promising continuity. A backup of references alone is not a verified recovery plan.

A focused planning checklist

• Record the product scope, economic roles and applicable transition analysis.
• Separate execution, paid upgrades and assessed security support in checkout and documentation.
• Keep an authorised fix path available when feature maintenance expires.
• Assign incident triage and reporting responsibilities, including holiday cover.
• Maintain release evidence and test update authenticity, rollback and supported environments.
• Explain support dates, contact routes and end-of-support behaviour consistently.

This checklist addresses licensing-related planning only. It is not the CRA's complete requirements or a readiness score. Revisit the official sources and product assessment when the release, dependencies or rules change.