NIS2 Secure Development and Product Security

In this lesson

Locate secure development in article 21: the measure named in point (e) of paragraph 2, the risk base of paragraph 1 and the supplier view of paragraph 3.
Decide whether point 6 of the Annex to Implementing Regulation (EU) 2024/2690 binds your entity or serves only as a reference.
Apply one set of development rules to software built in-house and software built for you by others.
Keep apart what NIS2 asks of an entity and what the Cyber Resilience Act asks of a manufacturer.

Where development sits in article 21

Article 21(2) lists the ten measures that every essential and important entity must include at least. Point (e) is the one that concerns anyone who writes, buys or maintains software: “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. Read the three nouns as a life cycle. Acquisition is the moment you choose and buy a component or a system. Development is the moment you build or adapt it. Maintenance is everything that happens afterwards, from patches to configuration changes, until the system is retired. The tail of the sentence, vulnerability handling and disclosure, runs through all three.

Point (e) does not stand alone. Article 21(1) sets its purpose: entities take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services”. Software falls squarely within those systems. Article 6(1)(b) defines a network and information system as including “any device or group of interconnected or related devices, one or more of which, pursuant to a programme, carry out automatic processing of digital data”, and point (c) adds the data stored, processed, retrieved or transmitted by them. The customer portal, the billing engine, the integration scripts between them and the data they carry are all in.

The same paragraph tells you how far to go: a level of security appropriate to the risks, judged on the entity's exposure, its size, and the likelihood and severity of incidents. A spreadsheet macro used by three people and the application that dispatches ambulances do not deserve the same process. Article 21 asks that you can explain the difference.

Who carries the obligation

Art. 20(1)

NIS2 is a directive addressed to member states. Article 21 requires them to ensure that entities take the measures; national law places the duty on the entity. No provision of NIS2 is addressed to an individual developer, architect or tester: they are the people through whom the entity complies.

Under article 20(1), the management bodies of essential and important entities approve the cybersecurity risk-management measures taken to comply with article 21, oversee their implementation and can be held liable for infringements of that article by the entity. Your secure development rules are part of those measures: written, approved, and visible enough for the management body to see whether they are applied.

Training follows the same logic. Cybersecurity training is one of the entity's own measures under article 21(2)(g). For the entity types bound by Implementing Regulation (EU) 2024/2690, point 8.2.1 of its Annex requires them to identify employees whose roles require security-relevant skill sets and expertise and ensure that they receive regular training on network and information system security. Developers and the people who review and release their work fit that description.

In-house or outsourced, the same rules

Recital 83

Recital 83 removes a tempting escape route: the measures “should apply to the relevant essential and important entities regardless of whether those entities maintain their network and information systems internally or outsource the maintenance thereof.” If an agency writes your mobile app, the risk to your systems and your customers is still yours to manage.

Implementing Regulation (EU) 2024/2690 makes the point operational for the entities it binds. Point 6.2.1 of its Annex requires them, before developing a network and information system, including software, to lay down rules for secure development and apply them “when developing network and information systems in-house, or when outsourcing the development of network and information systems.” Point 6.2.3 adds that for outsourced development they also apply the supply chain policies of point 5 and the acquisition processes of point 6.1. The contract becomes the vehicle for your development rules: the supplier works to them, or to rules you have checked are at least equivalent, and you keep the right to verify.

Implementing Regulation (EU) 2024/2690: binding or reference?

Reg. 2024/2690, art. 1, Annex 6

Article 1 of the Implementing Regulation lists the entity types it binds: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers. For those relevant entities, article 2(1) states that the technical and methodological requirements of the article 21(2) measures are set out in its Annex. For every other essential or important entity, a hospital, a water utility, a manufacturer, the Annex is not an obligation. It is a detailed official description of what point (e) can involve, and a useful reference, but the binding detail for those entities comes from national law. What your member state has adopted is on the transposition tracker.

Point 6 of the Annex, headed with a reference to article 21(2)(e), has ten parts: security in acquisition of ICT services or ICT products (6.1), secure development life cycle (6.2), configuration management (6.3), change management, repairs and maintenance (6.4), security testing (6.5), security patch management (6.6), network security (6.7), network segmentation (6.8), protection against malicious and unauthorised software (6.9), and vulnerability handling and disclosure (6.10). This course works through the parts that concern development teams.

Point 6.2 is the core. The rules “shall cover all development phases, including specification, design, development, implementation and testing.” Under point 6.2.2, the relevant entities:

analyse security requirements at the specification and design phases of any development or acquisition project;
apply principles for engineering secure systems and secure coding principles, “such as promoting cybersecurity-by-design, zero-trust architectures”;
lay down security requirements regarding development environments;
establish and implement security testing processes in the development life cycle;
appropriately select, protect and manage security test data;
sanitise and anonymise testing data according to the risk assessment.

Point 6.2.4 requires the rules to be reviewed and, where necessary, updated at planned intervals. Several requirements in the Annex apply “where appropriate” or “where applicable”. Article 2(2) of the Regulation requires an entity that considers such a requirement not appropriate, not applicable or not feasible to document its reasoning in a comprehensible manner, as recital 6 also explains. A blank is not an answer; a reasoned exclusion is.

When you are someone else's supplier

Art. 21(3)

Secure development appears a second time in article 21, from the other side of the contract. Under article 21(3), when entities decide which supply chain measures are appropriate, they take into account “the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures.” Point 5.1.2(a) of the Annex to Implementing Regulation (EU) 2024/2690 turns this into a selection criterion for the relevant entities. A software company that is not itself in scope will still be asked to describe, and sometimes prove, how it builds software, because its customers must take that into account. The rules you write for yourself under point (e) are also the answer you give to them.

Where the Cyber Resilience Act comes in

Reg. 2024/2847, recital 3

Regulation (EU) 2024/2847, the Cyber Resilience Act, regulates something else. It sets essential cybersecurity requirements for products with digital elements made available on the EU market, and it places them on manufacturers and the other economic operators that supply those products. Its recital 3 is explicit that existing Union law, NIS2 included, “does not directly cover mandatory requirements for the security of products with digital elements.”

NIS2 asks an entity to secure the systems it uses; the CRA asks a manufacturer to secure the products it places on the market and to handle their vulnerabilities for a support period. One company can be both, and an entity buying software benefits from what the CRA requires of its supplier. But a CRA obligation never becomes a NIS2 obligation by analogy. Lesson 4.2 sets out where the two meet; until then, when this course mentions the CRA, it says so.

In practice

Invented case. A drinking water supplier with 900 staff and a turnover of EUR 140 million is an Annex I entity above the medium-sized ceilings, so an essential entity under article 3(1)(a). It is not one of the entity types in article 1 of Implementing Regulation (EU) 2024/2690. It runs three development streams: an in-house team of eight building the customer portal, an agency building the customer mobile app, and two engineers writing scripts that move data from the treatment plants' historian into the reporting platform.

The security manager lists all three streams in one inventory and writes a single secure development standard, using point 6.2 of the Annex as a reference while recording that the Implementing Regulation does not bind the company. The standard grades effort by risk: the portal and the historian scripts carry full threat modelling and security testing; an internal dashboard carries a lighter checklist. The agency contract now requires work to the standard, a component list with each release and a right to review test results. The management body approves the standard with the other article 21 measures.

What a supervisor will ask

Show me your secure development rules and who approved them. The written standard, with the record of its approval by the management body as part of the article 21 measures.
Which systems do these rules cover? An inventory of development activity, in-house and outsourced, with the risk grade applied to each.
How do the rules reach your outsourced developers? The contract clauses, acceptance criteria and the evidence you received at the last delivery.
Does Implementing Regulation (EU) 2024/2690 apply to you? A short written analysis against its article 1, and the national measures you follow instead if it does not.

Key points

Article 21(2)(e) covers acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure.
The obligation falls on the entity, through national law; management bodies approve the measures and oversee them under article 20(1).
Outsourcing development does not outsource the risk; for relevant entities, point 6.2.1 of the Annex to Implementing Regulation (EU) 2024/2690 applies the rules to in-house and outsourced development alike.
That Annex binds only the entity types in its article 1; for other entities it is a reference, and national law sets the detail.
Article 21(3) makes your secure development procedures something your NIS2 customers must take into account.
The Cyber Resilience Act binds manufacturers of products with digital elements; it is a separate regime that meets NIS2 without merging with it.