A 36-month countdown to compliance with the EU 

Vendors of products with digital elements (PDEs) now have three years to fulfil all the law’s security requirements – which are focused heavily on eliminating vulnerabilities – if they want to sell their devices or software in the world’s largest trading bloc.

Cyber Resilience Act timeline, scope and penalties

 in the Official Journal of the EU on Wednesday (20 November). This means the act enters into force from 10 December. However, to give regulated organisations more time to prepare, most of the act’s provisions will apply from 11 December 2027.

Depending on the gravity of the offence, violations could result in fines of up to €15 million, €10 million or €5 million, or, respectively, up to 2.5 %, 2% or 1.5% of an entity’s worldwide annual turnover (whichever is higher). Offending products could also be banned from sale within the single market.

PDEs are defined as any software or hardware that connects to networks or other devices. That definition covers the vast majority of modern devices, from smartphones, laptops and tablets to smart TVs, cameras and toys. There are certain exemptions for open-source software, and products covered by existing rules, such as medical, aviation and automobile products.

EU CRA focused on tackling ‘widespread vulnerabilities’

 in 2022 to address “a low level of cybersecurity” in digital products, the European Commission set out to tackle certain deficiencies above all. As well as observing a lack of security information provided to users, it noted “widespread vulnerabilities and the insufficient and inconsistent provision of security updates to address them.”

As a result, the European Cyber Resilience Act has a big focus on identifying, disclosing and fixing vulnerabilities.

For instance, products must arrive on the market in a secure-by-default configuration (with certain exceptions) and free from “known exploitable vulnerabilities”. Identifying the presence of known vulnerabilities is facilitated by the mandatory creation of a 

 (SBOM), which must cover a product’s top-level dependencies as a minimum.

Vulnerabilities should be addressed and remediated “without delay”, the CRA instructs.

Bug Bounty backed by the Cyber Resilience Act

The CRA requires that coordinated vulnerability disclosure policies (CVD policies or VDPs) are implemented to facilitate the external reporting of vulnerabilities, both directly to the vendor “and where requested anonymously, via CSIRTs”. There should also be a single point of contact to which vulnerability information can be relayed and where the CVD policy can be found.

Bug Bounty Programs are explicitly referenced as a vehicle for fulfilling CVD obligations. “Given the fact that information about exploitable vulnerabilities in widely used products with digital elements can be sold at high prices on the black market, manufacturers of such products should be able to use programmes, as part of their coordinated vulnerability disclosure policies, to incentivise the reporting of vulnerabilities by ensuring that individuals or entities receive recognition and compensation for their efforts,” reads the act. “This refers to so-called ‘bug bounty programmes’.”

The Cyber Resilience Act 2024 also urges member states to protect vulnerability researchers from legal harms by adopting “guidelines as regards the non-prosecution of information security researchers and an exemption from civil liability for their activities”.

Specific Cyber Resilience Act requirements are detailed for “high-risk AI systems”, including accounting for “AI specific vulnerabilities such as data poisoning or adversarial attacks, as well as, as relevant, risks to fundamental rights”.

Security updates should be distributed promptly, securely and free of charge, and be accompanied by security advisories, according to the CRA. Where applicable, they should be automatic or separate from functionality updates.

Once patches have been issued, manufacturers are obliged to publicly disclose remediated vulnerabilities, providing a description and information about impact, severity and remediation/mitigation. However, disclosure can be delayed to give users more time to apply patches where “manufacturers consider the security risks of publication to outweigh the security benefits”.

Manufacturers are also expected to notify Computer Security Incident Response Teams (CSIRTs) and ENISA, the EU cyber agency, about “severe incidents” and the active exploitation of vulnerabilities. These requirements apply in 21 months, from 11 September 2026.

Recognising the complexity of the threat landscape, lawmakers have designed the CRA to increase cyber-resilience both throughout the supply chain and lifecycle of digital products.

Vendors must handle vulnerabilities for a minimum support period of five years, unless the product’s lifetime expires sooner. Longer support periods are prescribed for typically long-life components like microprocessors, network devices and operating systems.

When support periods end, “manufacturers should consider releasing the source code of such products” to the public domain or “other undertakings which commit to extending the provision of vulnerability handling services”.

Other CRA requirements cover areas such as authentication, encryption, minimising attack surfaces, reducing the impact of cyber-attacks, and the collection of personal data.

Irrespective of their place of manufacture, PDEs must be compliant if they are sold in the EU single market, encompassing 27 member states plus Norway, Iceland and Liechtenstein. Alongside safety, health and environmental protection standards, CRA compliance is now a condition of bearing a CE mark.

The CRA forms a key plank of the EU’s recent drive to upgrade its cybersecurity framework. Other notable pillars are 

 (introduced a common certification framework for ICT products), 

NIS 2 (Network and Information Security) Directive

 (wide-ranging requirements for member states and ‘essential’ or ‘important’ services) and the 

 (ICT security rules for financial services firms).

These regulations all prioritise – in common with cyber laws emerging elsewhere in the world – a risk-based approach to understanding and minimising your attack surface, and proactively finding, fixing and remediating vulnerabilities.

YesWeHack crowdsourced security testing and VDP solutions can help you fulfil your compliance obligations in a scalable and cost-effective fashion. In particular:

 that provides agile security testing adapted to your development model, results-based pricing, in-house triage, seamless integration with your security tools and more secure development practices

 of our Bug Bounty and vulnerability management platform.

Cyber Resilience Act: compliance countdown set to start for EU law focused on eliminating vulnerabilities

Attack surface discovery: mapping your exposed vectors with continuous threat exposure management (CTEM)

Mapping an organization’s attack surface is the fundamental first step towards hardening exposed attack vectors.

From web applications to APIs and cloud infrastructure, 

 involves systematically identifying all your internet-facing assets.

Gaps in your inventory of online assets – the ‘known unknowns’ and//or ‘unknown unknowns’ – can exist due to misconfigurations, shadow IT, complex architectures, rapid digital transformation, siloed acquisition of tech, and inadequate asset management processes.

Automated vulnerability scans, pentesting engagements and, in particular, 

 offer effective risk mitigation for tackling your known risks. By definition, they cannot include unknown assets.

But conducting attack surface discovery in an automated and exhaustive fashion, you can then identify, prioritise and fix vulnerabilities across all possible attack vectors, including previously hidden assets.

Yet if the mantra “you cannot secure what you cannot see” is widely understood, far too many CISOs nevertheless have only a patchy overview of their attack surface. More than two thirds of organisations have admitted to having been compromised via an unknown or poorly managed internet-facing asset (IBM report, 2021).

Without the right attack vector analysis tools, InfoSec teams can struggle to identify – let alone secure – their proliferating online assets.

According to TechTarget, 62% of organizations’ attack surfaces have increased over the past two years as organisations launch new apps and websites, store more data in the cloud, add new third-party integrations, use IoT devices and so on. Frequent software updates also heighten the risk of assets going online, or inadvertently remaining online, without security teams realising.

The merits of CTEM in attack surface discovery

So what’s the best way to perform attack surface mapping?

There are many methods and attack surface discovery tools for ascertaining your potential attack vectors: manual network architecture reviews, user access reviews, network scanners, asset management tools, Cloud Security Posture Management (CSPM) tools, attack surface domain discovery tools and Security Information and Event Management (SIEM) systems to name a few.

When it comes to achieving a unified, comprehensive and real-time overview of your internet-facing assets, an increasingly essential model is Continuous Threat Exposure Management (CTEM).

CTEM is a five-step automated process for continuously monitoring an organisation’s environment for new attack vectors, discovering the attack surface’s exposure to vulnerabilities, and remediating the most critical weaknesses first. Implemented well, this can provide a unified, comprehensive and risk-based approach to security testing.

Given your constantly evolving attack surface and the persistent probing of malicious hackers, this continuous and real-time overview of your cyber risks is preferable to periodic ‘point in time’ snapshots.

With digital transformation, accelerating release schedules and tight security budgets demanding an always-on, cost-effective and scalable approach, tech research firm Gartner cited CTEM as a top strategic technology trend for 2024. It forecasts that, by 2026, organisations implementing a CTEM program now could benefit from a two-thirds reduction in breaches.

 enables five operational phases in accordance with the CTEM model. Mapping your attack surface encompasses the first two steps: SCOPE and DISCOVER.

With YesWeHacks’ ASM, you kickstart the CTEM process by ‘scoping’ your assets: declaring your domain names and IP ranges/addresses and letting our solution inventory subdomains, accessible services and associated technologies.

Then our backend scanners can ‘discover’ related subdomains, other domains hidden from the organisation (due to shadow IT for instance), reachable services and associated technologies. Subsequently, they will continuously detect, and notify you of, any newly-surfaced online assets. A value is assigned to each discovered and classified asset according to its business criticality.

The subsequent CTEM phases, which we will cover in future articles, include PRIORITISING the most pressing suspected vulnerabilities discovered across your exposed vectors, through auto-generated priority scores; VALIDATING or rejecting a finding as exploitable in your environment; and MOBILISING by accessing, editing, sharing, assigning and tracking vulnerability reports from all sources to efficiently fix the most urgent security flaws first. In a follow-up article, we will also explore the potential synergy between Bug Bounty Programs and CTEM – with benefits including optimised testing coverage and cost-effective hardening of your exposed vectors.

How the YesWeHack ASM strengthens your security posture

YesWeHack’s ASM product can provide the missing link in your offensive security strategy by providing:

– mapping internet-facing assets and exposed dependencies

Continuous visibility of your organisation’s 

Automated prioritisation of vulnerabilities 

based on an easy-to-understand algorithm – accounting for severity (using CVSS), in-the-wild exploitability (using EPSS) and the related asset’s criticality value (assigned by the client organisation)

Strategised security testing and remediation to 

tackle the most critical vulnerabilities at scale

The turnkey-deployable ASM integrates seamlessly with the existing YesWeHack platform. Vulnerabilities from various security testing channels, including automated scanning by the ASM, Bug Bounty programs, traditional pentesting and Vulnerability Disclosure Policies (VDPs), are therefore consolidated into the same interface. This provides a one-stop-shop for all vulnerabilities – whatever their source and format.

 with YesWeHack today and discover how a risk-based approach can transform your organisation's security strategy.

Security teams are sometimes apprehensive about crowdsourcing security testing for the first time.

But initially cautious YesWeHack customers often become more ambitious – adding scopes, increasing rewards or inviting more hunters – as their concerns are assuaged, according to the head of the Bug Bounty platform’s triage team.

“Ensuring customers get clear, relevant and actionable vulnerability reports gives customers confidence in the process,” says 

, YesWeHack’s head of security analysts and researcher enablement. “This emboldens them to steadily expand the program and perhaps eventually launch a public program open to all registered and vetted hunters.”

In turn, this regular addition of new hunting opportunities keeps hunters engaged, adds Adrien, a still-active bug hunter who discovered Bug Bounty in 2017.

“In essence: happy customers equal happy hunters and vice versa. It’s a virtuous circle we strive to facilitate.”

Founded and run by ethical hackers, YesWeHack also aims to keep customers and hunters happy by handling reports swiftly and objectively, therefore enabling customers to pay rewards promptly. To sustain this approach, the in-house triage team is expanding to accommodate YesWeHack’s ongoing growth, as well as operating 24/7.

Automation as well as manpower are key as the team’s workload increases, although Adrien insists that “we cannot automate everything. We can automate some easy Proof of Concepts [PoCs], facilitate initial severity assessment, and streamline repetitive, basic triage tasks.”

Triage is conducted by full-time triagers and supervised by each customer’s dedicated customer success manager (CSM). Triagers perform the following for every report:

the finding in line with the scope, qualifying vulnerabilities and other rules

 using a CVSS calculator, in consultation with the customer

, such as root cause analysis or impact assessment

“It's like a compliance check,” says Adrien.

And if the impact demonstrated by a PoC is less than the impact reported, the triagers liaise with the researcher to try and bridge this gap with additional evidence. When the converse is true – a higher impact demonstrated – the customer is promptly notified.

The knowledge accumulated from previous findings sometimes gives triagers valuable insights that the hunter might lack. “A hunter might, for instance, send a PoC for an SSRF, and we know that in the past a similar report has been evaluated with a higher impact than initially estimated after internal checks by the program,” explains Adrien.

But while triagers sometimes make such suggestions, Adrien emphasises that clients are not obliged to follow their advice. “The triage team does not make the final decision on severity, because we can’t always know everything about the impacted asset,” he insists. “If the customer has information about the technology that we don’t, we need to trust their opinion. Severity is assessed based on our experience, the customer’s knowledge and the context of the digital asset.”

The systematic prioritisation of incoming reports is a key plank of the YesWeHack model’s success (something attested to in our 

). This is based on not just on when they are submitted, but also severity and an initial evaluation of potential real-world business impact by the triage team. “If a report is validated as truly critical, it gets triaged first,” says Adrien.

Nevertheless, the process is speedy as well as thorough regardless of severity. “YesWeHack has a first-response SLA of two business days for all reports but we’re actually achieving an average of 5-6 hours,” Adrien notes.

Triagers can also advise customers on the best course of action for out-of-scope submissions (a 

 is usually a good idea). For example, Telenor recalled in a 

 how vulnerabilities discovered in out-of-scope assets in their supply chain prompted them to alert affected suppliers, some of which went on to launch their own Bug Bounty Programs.

“The technical part of being a triager is important, but it’s not mandatory to have OSCP certification when you start for example,” says Adrien. Technical knowledge can be acquired on the job because new triagers’ assessments are doublechecked by colleagues during their first four months in the role. “So a new triager is never navigating the technical side alone,” says Adrien.

Soft skills are just as crucial. “We are intermediaries. We collaborate with both hunters and customers to address problems or complaints, respond to comments and ensure reports are as clear and accurate as possible.”

Interpreting and simplifying messages is a key part of this intermediary role: “Hackers often use different language and terminology to customers,” Adrien explains. “We explain the impact as clearly as possible to customers who might be new to Bug Bounty and not have great technical knowledge.”

The triage team keeps abreast of new vulnerabilities as technology evolves and developers become adept at preventing older bug classes like SQLi.

“In general, new bugs like large language model (LLM) injection, 

, OS binary or mobile app issues are more challenging for the triage team than classic vulnerabilities like XSS, CSRF and open redirects,” says Adrien. “When reports use new techniques, we need to understand the risks, impact and possible mitigations.”

Adrien expects to still be “triaging XSS and open redirects in five years’ time, but it’s vital for us to stay up to date with new techniques. That’s why we have an internal communication channel for sharing writeups and insights about the latest hacking techniques.” The triage chief recalls how the triage team once also “sharpened their technical skills by creating and participating in a CTF challenge”.

Hunting and triaging are increasingly automated, he acknowledges, but adds: “It’s important to keep the human brain involved in triaging to ensure the impact reflects the context, our knowledge and the customer’s knowledge.”

Also central to the efficiency of Bug Bounty Programs – and minimising customers’ workload – is the customer success management (CSM) team, which helps to continuously align scopes, bounty ranges, qualifying vulnerabilities and participating hunters with evolving customer requirements and budgets.

The CSM and triage teams have a symbiotic relationship. “The CSM team shares information that helps us do our job – for instance, if scopes are accessible via accounts with four levels of privileges,” says Adrien.

In return, “we are the eyes of the CSM team. For example, we will alert them if a scope is no longer available, or if a new API endpoint crucial to the application's operation has been forgotten and should be added to the scope.”

Moreover, triagers can help the CSM team recommend hunters with relevant skills. And if a new program is producing unremarkable reports, they might suggest “making the program rules more restrictive to really focus on impactful vulnerabilities”.

Asked for advice for CISOs navigating their first Bug Bounty Program, he highlights clear, unambiguous and timely communication with hunters. “What do you expect from the bug hunter? Keep your program description simple. If someone is on vacation and no one is available to check the report for a few days, warn the hunter. Or if you modified the CVSS, explain why you think the vulnerability is not critical in the context of your organisation.”

As for testing methodologies, he advises: “If it’s possible to provide accounts on the scope, do it, because this will help hunters and triagers to do their job.”

To conclude, what is the standout improvement in YesWeHack’s triage service during Adrien’s time at the company?

“The progress is in the process,” he says. “What started as a basic triage operation has evolved into a robust system with automation and seamless collaboration. I’m incredibly proud of how our team has grown and evolved – they've not only built an efficient process but have become trusted partners to our clients and security researchers alike.”

Interested in learning more about vulnerability triage or launching your first Bug Bounty program?

to see how YesWeHack can support and secure your digital assets!

‘Happy hunters equal happy customers and vice versa’: YesWeHack vulnerability triage chief Adrien Jeanneau on creating a virtuous Bug Bounty circle

 is now enforceable across the EU amid uncertainty about its implementation with most member states missing the deadline for transposing the regulation into national law.

Today was the deadline for member states to implement the wide-ranging cybersecurity legislation into national law. The EU’s two biggest economies, France and Germany, are among the countries to have missed this cut-off date. According to a 

 from the DNS Research Federation, Estonia and Portugal have yet to start the process for Article 28 ('Database of domain name registration data').

Confusion persists about the obligations entailed for in-scope entities. Some 38% of qualifying Irish businesses have yet to update their cybersecurity polices, for instance, and 67% cited complexity as the primary concern about implementation, 

according to a survey by Mason Hayes & Curran

With NIS 2 violations punishable by fines of up to €10 million or 2% of an entity’s total annual turnover, and senior management potentially held liable, the stakes for getting NIS 2 compliance right are high.

This NIS 2 explainer summarises the state of play, why NIS 2 has global implications, and outlines notable changes versus NIS 1, in particular ramifications for our area of expertise: security testing and vulnerability management.

NIS 2 Directive summary: changes versus NIS 1

Like its 2016 predecessor, the second iteration of the NIS (Network and Information Security) Directive is intended to achieve “a high common level of security of network and information systems across the Union”.

For member states, this means adopting national cybersecurity strategies, designating competent authorities and computer security incident response teams (CSIRTs), and providing tools and support to qualifying entities. Regulated organisations meanwhile must implement a raft of cybersecurity risk-management measures.

The headline changes versus NIS 1 include a wider range of in-scope sectors and their division into “essential” and “important” categories. Regulated sectors include banking, energy, transport and digital service providers such as online marketplaces, search engines and social networks. It has been estimated that around 300,000 institutions will be within scope, compared to just 20,000 under NIS 1.

Other notable changes include a 24-hour incident reporting deadline and stronger information-sharing measures.

There is also an emphasis, almost entirely absent from NIS 1, on securing supply chains and facilitating coordinated vulnerability disclosure (CVD). This reflects a changed threat environment amid the seemingly inexorable surge in new vulnerabilities since NIS 1 (see chart below). Among other measures, NIS 2 prescribes the creation of a European vulnerability database, while entities are instructed to undertake risk-management measures related to “vulnerability handling and disclosure”.

Meet ‘all hazards’ NIS 2 compliance requirements with CVD policies and attack surface management

 (PDF) that advise competent authorities to urge organisations to adopt their own CVD policy, while public authorities should demand the same from their suppliers and include CVD provisions in public procurement contracts. 

Launching a Vulnerability Disclosure Policy (VDP)

 is increasingly necessary, not just a ‘nice to have’.

Bug Bounty (or vulnerability reward) Programs

 as a vehicle for implementing CVD that produces strong results for “most organisations”.

The NIS 2 Directive prescribes an “all-hazards” approach to risk-management. Any strategy that duly aims to build resilience against all realistic threats must surely reckon with the proverbial ‘known unknowns’ and ‘unknown unknowns’.

And if security teams are to uncover hidden risks, and indeed comply with NIS 2 requirements on asset management and exposure to third-party risks, then continuously mapping and monitoring your attack surface is a must. Unsurprising then, the definitive methodology for achieving this, continuous threat exposure management (CTEM), is a 

 according to no less an authority than Gartner. Marry a 

CTEM-based approach with security testing from multiple sources

 and you’re particularly well positioned to mitigate known and unknown risks.

Enforcement is likely to be patchy and inconsistent at first. Only six member states – Belgium, Croatia, Greece, Hungary, Latvia and Lithuania – have seemingly adopted NIS 2 legislation ahead of the deadline. Many of the rest are expected to implement the regulation in the first half of 2025.

Since NIS 2 prescribes minimum requirements, there is room for flexibility in how laws are transposed. For instance, the 

 adds a CVD policy requirement to their new risk-management obligations, while “Germany is seeking to narrow the scope of national NIS2 regulation compared to the EU directive” in terms of which entities qualify, 

according to Daniel Widmann of Pinsent Masons

So while the NIS 2 Directive is intended to create uniformity across the EU’s regulatory landscape, there remain meaningful differences from state to state. In terms of deadlines for self-assessment/registration, NIS 2 compliance particulars and enforcement regimes, compliance teams must research the specifics of the jurisdictions they operate in.

Relevant details can be found on the websites of competent authorities (often the national cybersecurity agency or similar) along with various tools. For example, member states have provided (or are planning to provide) self-assessment tools for determining whether your organisation is within scope (among others, existing tools are available in 

Also guiding strategies for compliance are the sector an organisation operates in, its level of security maturity and compliance with various standards and frameworks. For instance, compliance with ISO 27001 (which 

) gives you a great springboard for NIS 2 compliance.

NIS 2 Directive: A De facto global standard?

NIS 2 has extra-territorial applicability, insofar as non-EU organisations must comply if they operate in the relevant sectors within the EU, and could be indirectly affected if they have partners or third-party suppliers in the trading bloc.

Clearly, market access to the world’s largest trading bloc is heavily contingent on compliance.

Moreover, perhaps NIS 2 compliance will become a sort of de facto global standard/aspiration given how 

GDPR inspired copycat data privacy regulations elsewhere

. Indeed, Geert van der Linden, executive VP of global cybersecurity services at Capgemini, has 

 that “NIS 2 will be seen as a global standard by judges”.

NIS 2 is just one of several far-reaching cybersecurity laws in force across the EU or in the pipeline. This includes the 

 (ICT security rules for financial services firms) and 

 (smart devices, with the UK having an equivalent in the 

The regulatory landscape is not so different elsewhere, with significant legislation in the pipeline in 

 for instance. Across the Atlantic, President Biden's 

 set in motion numerous initiatives and regulations. Significant new 

 also reflect a trajectory towards more prescriptive and punitive cybersecurity legislation amid growing economic and national security threats posed by state-backed malicious actors in particular.

NIS 2 and its implications for your SecOps strategy

To find out how YesWeHack can help you comply with NIS 2 and other cybersecurity regulations, 

CVD guidelines on implementing CVD policies

 for the ultimate CVD model – and benefit from agile security testing adapted to your development model, results-based pricing, in-house triage, seamless integration with your security tools and more secure development practices

 enables a unified, comprehensive and risk-based approach to security testing

The NIS 2 Directive is now enforceable: What are the implications for vulnerability management?

As EU member states scramble to transpose NIS 2 into national law, affected organisations are doubtless accelerating their compliance efforts as the transposition deadline (17 October) approaches.

There may be much work to do. After all, there were recent 

 of French organisations being underinformed about their new obligations.

NIS 2 aims to elevate and harmonise cyber-resilience across the bloc more effectively than its predecessor directive. Among other notable additions, national cybersecurity strategies and cybersecurity risk-management rules for “essential” or “important” entities must incorporate supply chain security and coordinated vulnerability disclosure (CVD) policies.

Belgium, the only member state to fully transpose NIS 2, has also mandated that qualifying entities publish a CVD policy. While this goes beyond what NIS 2 demands, perhaps some other member states will follow suit for reasons we’ll explain later.

NIS 2 should be of interest outside the EU too. Like the General Data Protection Regulation (GDPR), this landmark legislation may well inspire copycat regulations outside the bloc (it’s worth noting too that the UK is still updating its own NIS regulation post-Brexit).

This NIS 2 summary outlines the directive's key points, as well as the benefits of 

Continuous Threat Exposure Management (CTEM)

 for cost-effectively achieving compliance. 

 is the second iteration of the NIS (Network and Information Security) Directive, which broke ground as the first EU-wide cybersecurity rules when they came into force in 2016.

, the successor legislation is intended to achieve “a high common level of security of network and information systems across the Union”. It aims to do so by obliging:

Member states to adopt national cybersecurity strategies and designate or establish competent authorities, cyber crisis management authorities, single points of contact on cybersecurity and computer security incident response teams (CSIRTs)

Member states to give organisations tools, mechanisms and encouragement to share information on vulnerabilities, threat actors and so on

Organisations providing “essential” or “important” services to implement cybersecurity risk-management measures and promptly report “significant” security incidents

Member states to supervise and enforce compliance

The legislation sets out minimum requirements designed to achieve these goals that national laws will have to at least match, if not exceed.

The NIS 2 Directive entered into force in January 2023, from which point member states had 21 months to transpose its requirements into national law. The deadline of 17 October is now only four months away, with all but two countries (Croatia and Belgium) yet to transpose at the time of writing.

Regarding the obligations of in-scope entities, some requirements will apparently enter into force immediately, while others will be subject to a grace period.

Qualifying organisations must self-assess whether they fall within the scope of NIS2 and notify the relevant state regulator that they fall within NIS 2’s scope by 17 April 2025 (for some entities the deadline is 17 January). 

Why the original NIS Directive was superseded

 to be failing to embed sufficient and consistent cyber resilience across the EU and its critical sectors, create a common understanding between states about the threat landscape, or create a joint crisis response capacity. 

Among other measures, NIS 2 sets out to remedy these shortcomings by applying to a wider range of sectors, introducing incident reporting deadlines and strengthening information-sharing measures. It also introduces minimum financial penalties for violations and makes “management bodies” liable for infringements.

Vulnerabilities and supply chains to the fore

 post-2016 meant NIS 2 was drafted in a much-changed threat landscape to its predecessor.

While the word “vulnerability” appeared only once in the first NIS (and then only in relation to the obligations of CSIRTs), the term “coordinated vulnerability disclosure” appears 11 times in the NIS 2 Directive. Both member states and essential/important entities have obligations around vulnerability management or disclosure. The directive prescribes the creation of a European vulnerability database.

The first NIS was drafted before the game-changing 

 in 2020, which resulted in the downstream compromise of 18,000 customers (including government agencies). Whereas the first iteration did not even feature the term “supply chain”, NIS 2 mandates state-level risk assessments and entity-level measures on supply chain security.

The NIS 2 Directive broadens the scope of critical sectors and divides them into “essential” and “important” entities.

Four new sectors are added to the essential (or “high criticality”) tier, with space, waste water, ICT service management and public administration joining energy, transport, banking, financial market infrastructure, health, drinking water and digital infrastructure (which now also includes trust, cloud and other additional services).

The important category is populated by postal and courier services, waste management, chemicals, food, manufacturing, research and digital service providers, which span online marketplaces, search engines and social networks.

The NIS 2 regulation introduces, with certain exemptions, size and annual turnover parameters too (minimum 250/50 employees and €50m/€10m turnover for essential/important services). Member states have the discretion to make exceptions for high-risk entities that fall outside of these parameters.

Ireland’s National Cyber Security Centre has published a useful 

 (PDF) for understanding whether your organisation will be subject to NIS 2.

It has been estimated that around 100,000 companies in the EU will have to become NIS 2-compliant. YesWeHack qualifies as an ‘important’ entity and we have taken steps to comply.

NIS 2 essential and important entities must comply with risk-based security requirements arranged around six themes.

, management bodies must approve, oversee and be held liable for infringements of these NIS 2 controls. They must also undergo cybersecurity risk-management training and encourage their employees to regularly do likewise.

, meanwhile, “shall be based on an all-hazards approach” and cover a multitude of security areas, from cryptography to human resources security.

These measures should also tackle potential vulnerabilities in their supply chains, while entities should take into account 

coordinated security risk assessments of critical supply chains

Where entities use third-party ICT services, they may be required to use providers that are certified under pending 

European cybersecurity certification schemes

Best Practices

Cyber Resilience Act: compliance countdown set to start for EU law focused on eliminating vulnerabilities

Attack surface discovery: mapping your exposed vectors with continuous threat exposure management (CTEM)

‘Happy hunters equal happy customers and vice versa’: YesWeHack vulnerability triage chief Adrien Jeanneau on creating a virtuous Bug Bounty circle

The NIS 2 Directive is now enforceable: What are the implications for vulnerability management?

Countdown to NIS 2 compliance: Key insights and implications for your SecOps strategy

UK PSTI Act: ‘World first’ IoT security rules offer reminder of VDP virtues

The NIS 2 Directive is now enforceable: What are the implications for vulnerability management?

US SEC cyber rules, SolarWinds CISO charges: How a unified OffSec strategy can enhance your SEC disclosures

9 rules for a successful first-time Bug Bounty Program

Busting Bug Bounty misconceptions

US SEC cyber rules, SolarWinds CISO charges: How a unified OffSec strategy can enhance your SEC disclosures

How Bug Bounty and Attack Surface Management can help you comply with the Digital Operational Resilience Act’s upcoming requirements

Turnkey VDP Open Source: making a difference in enhancing cybersecurity as a “public good”

Let’s get the IoT landscape less vulnerable for all

How Bug Bounty and Attack Surface Management can help you comply with the Digital Operational Resilience Act’s upcoming requirements

Products

Researchers

Resources

Company

Follow us