Cybersecurity for Software Vendors: CRA Duties, NIS2 Supply Chain and Pentests

Which rules apply to you

If you sell software in the EU, the Cyber Resilience Act makes you a manufacturer with product duties, and your regulated customers add their own.

Cyber Resilience Act (EU) 2024/2847. Software is a product with digital elements under Article 3(1), and remote data processing your product needs is part of it under Article 3(2). Article 13 lists the manufacturer’s obligations: a risk assessment, conformity with the essential requirements of Annex I Part I (secure by default, no known exploitable vulnerabilities at release, protection of confidentiality and integrity, minimised attack surface, logging), the vulnerability handling of Annex I Part II (a software bill of materials, remediation without delay, regular testing, a coordinated vulnerability disclosure policy, security updates separate from feature updates and free of charge for the support period), and a support period that is at least five years under Article 13(8) unless the product is clearly used for less. Article 14 adds reporting of actively exploited vulnerabilities and severe incidents from 11 September 2026. Everything else applies from 11 December 2027 with CE marking. Products in Annex III, such as operating systems, browsers, password managers, VPN and identity management software, are important products with stricter conformity assessment. Article 24 creates the open-source steward role; non-commercial open source is out of scope.

NIS2 via the German BSIG. Your customers in regulated sectors must manage supply chain security under Article 21(2)(d) of the Directive and § 30 BSIG, which arrives at you as security questionnaires, contractual audit rights and incident notification clauses. Managed service and managed security service providers are entities in their own right under Annex I.

DORA (EU) 2022/2554 applies when your customers are financial entities: Chapter V turns you into an ICT third-party service provider with mandatory contract terms, audit and exit provisions.

GDPR Articles 28 and 32 govern you as a processor and require appropriate technical measures, including regular testing of their effectiveness.

Where attackers start

For a software product the perimeter is the API and the release pipeline.

• Authentication and session handling: token validation, password reset flows, single sign-on integrations, long-lived API keys.
• Authorisation: object-level and function-level checks across tenants, the most common weakness in multi-tenant products.
• Input handling: injection in search, filters, file uploads, templates and report generation, server-side request forgery into cloud metadata.
• Dependencies and build: outdated libraries with known CVEs, CI/CD secrets, unsigned release artefacts, container images built from unknown bases.
• Installers and on-premises deployments: default credentials, bundled databases listening on all interfaces, update channels without signature verification.
• Integrations: webhooks, OAuth clients, plug-ins and import formats that trust the other side.

What assessments typically find

Typical findings from web, API and backend penetration tests of commercial software, anonymised: an API that returned any tenant’s records when the object identifier in the URL was changed, because authorisation was checked at the endpoint but not at the object; JSON web tokens accepted without audience check, so a token from the free tier opened the paid product; mass assignment that let a user set their own role; server-side request forgery from a URL preview feature into the cloud metadata service and from there to credentials; an administrative interface on a non-standard port without authentication in the on-premises installer; a mobile client bundling the backend’s signing secret; and dozens of dependencies with published CVEs in the shipped image.

Under the CRA the last point alone is a conformity gap: Annex I Part I requires products to be delivered without known exploitable vulnerabilities.

A sensible first project

Start with the product that has the most customers under NIS2 or DORA, since that is where the questionnaires come from.

1. Scoping and classification: which parts are placed on the market, which are remote data processing, whether the product is an Annex III important product, which support period you commit to. One day.
2. Grey-box penetration test of the application and its API with test accounts in two tenants, plus a review of the installer or container image and the cloud configuration. One to two weeks.
3. CRA gap analysis of your release process: SBOM generation, vulnerability intake and triage, coordinated disclosure policy and security.txt, the 24-hour reporting runbook, update signing and the separation of security from feature updates. Three to five days.
4. Fix and retest, then move scanning, dependency checks and SBOM generation into the pipeline so the next release starts ahead.

Typical effort for steps 1 to 3 is 12 to 20 person-days, which is 15,000 to 32,000 euros at market rates. Many vendors fund it from the sales cycle it unblocks.

What Zyberum does and does not do here

We test web applications, APIs, cloud environments and mobile clients, review code and build pipelines, do CRA gap analyses, write the vulnerability handling and disclosure processes and train development teams in secure coding. We help you answer customer questionnaires with evidence rather than promises. We are not a notified body and do not issue CE marks or certificates, we do not sell scanners or other third-party security products, and we test only with your written authorisation.