There is more to NIS2 than 'yet another punishing regulation'. Let's explore what it means in the context of software development.

The EU Network and Information Security Directive (NIS, 2016/1148) was originally created to establish and enforce a cybersecurity baseline for critical digital infrastructure (digital service providers and operators of essential services) with a focus on risk management and incident reporting. Failure to comply can carry massive penalties just like GDPR breaches (the higher of 10 million EUR or 2% of last year’s worldwide turnover, see Article 34) alongside possible criminal sanctions for management – even if one is not considering the possible harm a malicious hacker can cause by compromising a critical piece of a country’s digital infrastructure, these penalties are providing enough incentive to encourage compliance!

The scope of NIS2 encompasses any medium or larger enterprise in any of the critical sectors mentioned in the document from banking to waste management. Some of these sectors can have their own domain-specific cybersecurity regulations (e.g. DORA for financial entities) that can be more strict – and thus take precedence over – NIS2. The first version of NIS had many difficulties in implementation due to unclear wording, so NIS2 (2022/2555) broadened its scope and got much more strict and specific about its requirements.

That said, NIS2 is a set of measures, not a specific standard and EU member states are supposed to “transpose” (implement) it – see the ECSO’s tracker here. Ideally there’d be a way to certify products that comply with NIS2, but this is still under development (see EU CCF). Thus, for companies that want actual actionable requirements and recommendations, the ENISA (EU Agency for Cybersecurity) Technical Implementation Guidance document serves as a better starting point alongside established standards with similar goals such as ISO 27001.

But what about product security?

Paragraph 2 of Article 21 (Cybersecurity risk-management measures) outlines the main cybersecurity requirements in 10 bullet points. While some of these are about organizational measures, 6 points are connected to product security:

• Supply chain security
• Security in ICT acquisition, development, deployment, vulnerability handling
• Cybersecurity training
• Policies and procedures for the use of cryptography and encryption
• Access control policies
• Multi-factor or continuous authentication solutions, secure communication

Every (supply) chain has its weakest link

Often it is much easier to compromise a system by attacking components the developer had no control over. In this case, it “is not your fault, but is still your problem”. This can mean third-party packages or libraries used by the developer, but it can also mean compromising the development or runtime environment. The infamous SolarWinds attack of 2020 started by infecting a software company’s build system to turn their network management software against its users, and ended up compromising the systems of many governmental entities in the US in the end. More recently, the “Shai-Hulud” self-replicating worm in the npm package manager registry infected hundreds of package developers and has inspired numerous copycats such as “Mini Shai-Hulud” (May 2026). It’s little wonder that supply chain failures now take up the #3 position on the OWASP Top 10 2025 (as opposed to #6 in 2021, and #9 in 2017).

ENISA has several recommendations in this area, mainly monitoring suppliers and assessing their risk (even auditing them if needed) while also avoiding vendor lock-in so any of them can be replaced in case of unacceptable performance or their product reaching end of life. ENISA also has some baseline requirements suppliers should meet to consider them acceptable: in a nutshell, only use suppliers that apply secure-by design best practices for their product security (and the same requirements should apply to your own product, see later) while also being transparent about their security posture and data handling.

In addition to all that, vulnerability management is the responsibility of the developer to keep track of any vulnerabilities in their own components using technologies like the Software Bill of Materials (SBOM) alongside automated Software Composition Analysis (SCA) tools. This also necessitates a process in place for releasing security hotfixes outside of the regular patch cycle if needed.

Security is not just something to ‘add at the end’

NIS2 covers both secure software development and deployment in (2)(e) of Article 21, and ENISA’s indispensable baseline security requirements are clear: “[Secure] by design – the product, or service, has been conceived, designed and implemented to ensure the key security properties are maintained: availability, confidentiality, integrity and accountability.”

It is widely recognized that the sooner a software defect is identified, the less costly it is to correct. This principle, documented in studies such as the 2002 NIST report, is even more significant for security issues. For example, discovering during a security audit that a production system has stored passwords in plaintext for years can require extensive remediation, whereas addressing the same flaw during the design phase would have been far simpler and far less expensive.

Concepts such as secure by design and shift left reflect this fundamental approach rather than serving as mere industry buzzwords. Security should be considered from the outset of a project and integrated throughout development instead of being added after implementation. Following a secure Software Development Lifecycle (SDLC) framework – such as BSIMM, SAMM, or Microsoft SDL – helps organizations embed security into every stage of the development process.

During the requirements phase, CIAA (Confidentiality, Integrity, Availability, Authenticity) should be established and analyzed, and used during the design and implementation phase to drive the design of security controls. Threat modeling and risk assessment should be an organic part of the design process. Developers should adopt secure coding techniques and following secure coding standards to avoid common vulnerability types. Finally, during deployment, hardening techniques can reduce the attack surface (the potential points where an attacker may be able to access or manipulate the system) by removing unnecessary components and configuring everything to be as secure as possible.

None of the ideas behind the secure-by-design paradigm are novel or particularly complicated – Saltzer and Schroeder’s 8+2 principles of secure software design have been around since 1975! – and they are essential to put the security of a system on a solid foundation.

Cryptography: no need to reinvent the wheel

Protecting the security (especially confidentiality and integrity) of data is perhaps the most important security requirement, and cryptography gives us the necessary tools to do that. Article 21 (2)(h) clearly includes policies and procedures regarding the use of cryptography and encryption in the scope of NIS2. Chapter 9 of the ENISA implementation guidance document gives specific guidance here. It clearly states that well-established and accepted algorithms and protocols should be used instead of trying to do ‘ad hoc cryptography’ (cryptography is emphatically a “don’t do this at home” discipline – see e.g. the mistakes Zoom made in 2020 when they ‘rolled their own crypto’). The first step is using the right algorithm (i.e. don’t use hashing by itself for integrity protection; or don’t use DES, SHA-1 or any other obsolete algorithm at all), but that’s not the end of the story. For example, the most commonly used encryption algorithm (AES) has several potential pitfalls or ‘footguns’ if a developer is unfamiliar with the algorithm and established best practices – see our article on AES for more details on issues like using the wrong mode of operation, not verifying padding, or reusing the initialization vector (IV).

More on the management side is the handling (creation, maintenance, use, protection, deletion) of cryptographic keys and other secrets, and ENISA gives many recommendations here as well. Note that there is a current proposal to necessitate the use of post-quantum cryptography after 2030/2035 as quantum computing is expected to make several algorithms obsolete. Thankfully the most commonly used encryption algorithm (AES) isn’t broken by these algorithms, though larger key sizes will be needed (AES-256).

Access control

When it comes to protecting data at rest, access control (i.e. authentication + authorization + accounting) is just as relevant as cryptography. It is mentioned in Article 21 (2)(i). Chapter 11 of the ENISA recommendation is dedicated to adherence to industry best practices in this area when establishing policies and implementing access control systems. Of course, there is no ‘one size fits all’ solution for creating an access control policy, but Saltzer & Schroeder’s previously mentioned principles of secure software design (above all, separation of privilege and the principle of least privilege) serve as a strong starting point. The needs of the business can define whether it is enough to go with a discretionary access control (DAC) model or a much more strict mandatory access control and role-based access control – and similarly, whether a standard role-based access control (RBAC) model is enough or if a more fine-grained attribute-based (ABAC, sometimes also called ‘claims-based access control’) model is warranted.

Authentication – verifying an entity’s identity – is a particularly error-prone element of access control, which is why it has its own focus in Article 21 (2)(j) and sections 11.6-7 of the ENISA guidance document. You can also check out our article on the science and art of authentication that goes more into detail on its various aspects and the potential threats to be aware of – especially when it comes to password management!

The limitations of ‘security for the sake of compliance’

Compliance frameworks play an important role in strengthening an organization’s security posture, but they should not be mistaken for security itself. Organizations can easily fall into the habit of treating compliance as a checklist exercise, assuming that meeting documentation and audit requirements is sufficient. In reality, an excessive focus on compliance alone may create blind spots and foster a false sense of confidence, while genuine security risks remain unaddressed.

Ultimately, compliance should be the outcome of sound security practices rather than the primary objective. When security is embedded into a system from the earliest design stages and maintained throughout development, satisfying compliance requirements becomes a natural by-product. Establishing a secure Software Development Lifecycle (SDLC) and integrating security activities into every phase of development enables organizations to build resilient systems while making compliance significantly easier to achieve.

NIS2 itself highlights the importance of training developers in secure software development – see recital (74) and Article 20 (2) in addition to the already-discussed Article 21, and the ENISA recommendations double down on this, especially in 8.2 (specifically mentioned as “Provide role-specific network and information security training”) and throughout Section 10 – though the importance of training is mentioned in almost every other section of the document as well. After all, secure coding is a team sport!