SpyCloud’s identity threat protection platform supports six NIS2 Article 21 risk-management measures – including incident handling, supply chain security, control effectiveness, access control, and authentication – through continuous identity exposure monitoring, investigation, and automated remediation.
The NIS2 Directive raised the cybersecurity bar across the EU, expanding cybersecurity risk-management and incident-reporting requirements across 18 critical sectors. European Commission estimates put at least 160,000 entities in scope, while essential entities can face fines of up to EUR 10 million or 2% of worldwide annual turnover.
The deadline for member states to adopt NIS2 into national law has passed, through implementation still varies. For organizations covered by NIS2 and their country’s implementing law, the practical challenge now is less about what the directive requires and more about proving those requirements are working.
That urgency shows up in the data. ENISA’s 2025 Threat Landscape found that 53.7% of recorded EU cyber incidents concerned entities classified as essential under NIS2.
For security leaders, that means looking beyond a compliance checklist at the ways attackers actually gain access: exposed identities, stolen credentials, compromised sessions, infostealer-infected devices, and third parties with access to critical systems.
These are areas where SpyCloud can help.
Where identity exposure fits into NIS2
NIS2 Article 21 requires covered entities to take appropriate and proportionate technical, operational, and organizational measures to manage cybersecurity risk. But controls inside the enterprise don’t always show security teams what has already escaped.
A password stolen in a third-party breach can be reused against a corporate application. An infostealer infection on an employee’s personal device can expose workforce credentials, session cookies, and other authentication data. A contractor or supplier can introduce another path into the organization when their authentication data becomes exposed.
And once authentication data leaves the organization’s control, infrastructure telemetry alone doesn’t tell the whole story.
Network and infrastructure intelligence can provide important context about malicious IP addresses, domains, command-and-control infrastructure, malware, and other indicators of attacker activity.
Identity exposure data answers a different set of questions:
- Whose identity is exposed?
- Which credentials or sessions were stolen?
- Which applications could be affected?
- What needs to be remediated?
That identity context matters when teams need to move quickly from detecting suspicious activity to understanding the people, authentication artifacts, and access at risk.
SpyCloud recaptures identity data from the criminal underground and connects those exposures to the identities, devices, applications, and third parties that matter to an organization. Security teams can use that data to investigate scope, identify exposed authentication data, and drive remediation before criminals can use it for follow-on attacks.
That’s the role identity threat protection can play in supporting Article 21 and operationalizing NIS2: providing evidence of identity risk that existing controls may not see, plus the context to act on it.
NIS2 supply chain security requires more than a vendor questionnaire
Supply chain security is an explicit NIS2 risk-management measure. Article 21(2)(d) requires organizations to address security-related aspects of their relationships with direct suppliers and service providers.
But supplier risk doesn’t wait for the next assessment.
The 2026 Verizon Data Breach Investigations Report found that breaches involving third parties increased 60% from the previous dataset and now account for 48% of all breaches.
The identity layer makes that risk particularly difficult to manage.
A contractor might enter corporate credentials into a shared application from a malware-infected personal device, an employee at a supplier could have an authenticated session stolen, or credentials tied to a vendor domain can appear in recaptured data from a breach, phishing, or malware long after the vendor’s last security questionnaire.
Annual assessments and vendor questionnaires still have a role. But they’re point-in-time evaluations of risk that changes continuously.
SpyCloud supports NIS2 Article 21(2)(d) supply chain security by continuously monitoring identity exposures associated with vendors and contractors, giving security teams visibility into exposed credentials and authentication data between assessments.
SpyCloud Supply Chain Threat Protection extends identity exposure monitoring to third parties, surfacing whether identities associated with a given supplier are exposed in ways that could put organizations at risk – something questionnaires can’t answer on their own.
How SpyCloud supports NIS2 Article 21 risk-management measures
SpyCloud’s identity threat protection capabilities directly support several NIS2 Article 21 risk-management measures, particularly sections 2(b), 2(d), 2(f), 2(i), and 2(j), with additional support for 2(e).
For the remaining measures, including policies on risk analysis, business continuity, cyber hygiene and training, and cryptography, SpyCloud data and alerts can provide inputs to support an organization’s own policies, controls, and training.
| ARTICLE 21 SECTION | NIS2 RISK-MANAGEMENT MEASURES |
HOW SPYCLOUD SUPPORTS IT: |
|---|---|---|
| 2(b) | Incident handling detects and responds to incidents affecting network and information systems |
SpyCloud supports NIS2 Article 21(2)(b) incident handling by identifying employee and supplier identities exposed through breaches, malware infections, and successful phishing, giving security teams identity context for investigation and response. SpyCloud automatically creates high-priority incidents from newly recaptured data and integrates with common SIEM and SOAR platforms to route exposures directly into existing triage and response workflows, and SpyCloud Research Agent can plan investigative pivots, correlate identities, and return findings tied to verifiable records – helping teams establish scope, severity, and root cause in minutes rather than relying on hours of manual pivot work. |
| 2(d) | Supply chain security, including security-related aspects of relationships with direct suppliers or service providers |
SpyCloud supports NIS2 Article 21(2)(d) supply chain security by monitoring vendor and contractor identity exposure, including exposed credentials and authentication data associated with third parties. Supply Chain Threat Protection extends visibility beyond point-in-time assessments to help security teams identify third-party identity risk as it changes. |
| 2(e) | Security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure |
SpyCloud provides additional support for NIS2 Article 21(2)(e) by identifying exposed accounts and authentication data associated with business applications. SpyCloud can also identify exposed developer and API secrets and infrastructure credentials tied to development environments – including those exposed through infostealer malware on unmanaged or supplier-owned devices – giving security teams information they can investigate and remediate before stolen authentication data puts systems and applications at risk. |
| 2(f) | Policies and procedures to assess the effectiveness of cybersecurity risk-management measures |
SpyCloud supports NIS2 Article 21(2)(f) by surfacing identity exposures and malware infections that have bypassed existing security controls. Recaptured identity data provides quantifiable exposure metrics across employees, contractors, and third parties – actionable evidence security teams can incorporate into risk analysis, reporting, and security policies, and use to evaluate whether existing controls and remediation processes are addressing real-world identity risk. |
| 2(i) | Human resources security, access control policies, and asset management |
SpyCloud supports NIS2 Article 21(2)(i) by continuously monitoring workforce identities for exposed authentication data associated with business applications. SpyCloud IDLink connects exposures across an individual’s past, present, personal, and professional identity footprint, including exposures originating from personal or unmanaged devices used for work. |
| 2(j) | MFA or continuous authentication solutions and secured communications, where appropriate |
SpyCloud supports NIS2 Article 21(2)(j) by identifying exposed credentials, session cookies, refresh tokens, and other authentication data that can undermine access controls. SpyCloud Identity Guardians can automate remediation through actions including password resets and session revocation, helping prevent criminals from using stolen authentication data for session hijacking and MFA bypass. |
SpyCloud doesn’t replace the controls NIS2 requires. It gives security teams visibility into identity exposures that can show where those controls have been bypassed and data they can act on when that happens.
NIS2 Article 23 incident reporting: why the "awareness" trigger matters
Article 21 establishes NIS2 cybersecurity risk-management measures. Article 23 creates a separate incident-reporting obligation – and a much shorter clock.
For a significant incident, covered entities must submit:
- Within 24 hours of becoming aware: an early warning to the national CSIRT or competent authority, including whether the incident is suspected to involve unlawful or malicious activity or could have cross-border impact.
- Within 72 hours of becoming aware: an incident notification with an initial assessment of severity and impact and, where available, indicators of compromise.
- Within one month of the incident notification: a final report detailing the incident, likely threat or root cause, mitigation measures, and cross-border impact where applicable.
The clock starts at ‘becoming aware’, not at the end of a completed investigation. That puts pressure on security teams to establish enough context quickly to understand whether they’re dealing with a significant incident and begin assessing its scope and impact.
Infrastructure context is part of that investigation. But it doesn’t answer every identity question.
Knowing the malicious infrastructure involved in an attack doesn’t necessarily tell a security team which employee credentials were stolen, whether an authenticated session is exposed, which applications those credentials access, or whether an infostealer infection originated from a personal device.
Identity exposure data helps fill that gap.
Recaptured credentials, session cookies, refresh tokens, and infostealer infection evidence can give teams an early signal that authentication data associated with their organization has been stolen. That context can help investigators understand the identities and access involved while they’re still establishing the broader scope and severity of an incident.
SpyCloud Research Agent can then accelerate the investigation by planning pivots across recaptured criminal-source data, correlating identities and infrastructure, and returning findings tied to underlying records. Investigations that traditionally require hours of manual pivoting can produce finished intelligence in minutes.
For a reporting clock measured in hours, that speed matters.
From malware infection to identity remediation
Infostealer malware illustrates why identifying an incident and addressing its remaining identity risk aren’t the same thing.
Removing malware from an infected device addresses the infection. It doesn’t automatically address what the malware already stole.
Credentials may still be valid. Session cookies may still provide authenticated access. Refresh tokens can allow an attacker to regain access even after other remediation actions. And other data stolen from the device can support follow-on attacks.
That’s why SpyCloud advocates for post-infection remediation: extending incident response beyond cleaning the infected device to address the identity exposures created by the infection.
SpyCloud helps security teams identify exposed credentials, sessions, and applications so they can take appropriate action, including resetting stolen passwords, revoking sessions and tokens, and cutting off access associated with exposed authentication data.
SpyCloud Identity Guardians can automate credential and session remediation through integrations with identity platforms including Active Directory, Entra ID, and Okta. For standard deployments, remediation can occur in under five minutes from detection.
Where NIS2 governance fits in
Article 21 establishes cybersecurity risk-management measures. Article 20 puts responsibility for approving and overseeing those measures on the organization’s management body.
No security vendor can fulfill that governance responsibility for an organization.
What security teams can give leadership is evidence.
Continuous visibility into identity exposures, remediation activity, and investigation findings tied to underlying data can help management understand where identity risk exists, how teams are responding, and whether existing measures are working as intended.
That evidence doesn’t replace governance. It makes governance more informed.
Turn NIS2 requirements into actionable identity risk reduction
NIS2 asks organizations to manage cybersecurity risk across their environments, people, access controls, and supplier relationships.
SpyCloud addresses a specific part of that challenge: identity and authentication data criminals have already stolen and can use to get around traditional defenses.
By continuously identifying exposed identities, credentials, session data, infostealer infections, and third-party exposures, SpyCloud gives security teams evidence they can use to investigate risk, drive remediation, and support NIS2 Article 21 risk-management measures.
And because identity exposure changes continuously, that visibility doesn’t stop at the last questionnaire, assessment, or audit.
Talk to an expert about NIS2 identity security
See how SpyCloud can help your team identify and remediate identity exposures that support your NIS2 cybersecurity risk-management program.
FAQs
NIS2 Article 21 requires covered entities to implement appropriate and proportionate cybersecurity risk-management measures. These include incident handling, business continuity, supply chain security, security in systems acquisition and maintenance, assessment of control effectiveness, cyber hygiene and training, cryptography, access control, asset management, and multi-factor or continuous authentication where appropriate.
SpyCloud provides identity threat protection capabilities that support several of these measures, particularly incident handling, supply chain security, control effectiveness, access control, and authentication.
For significant incidents, NIS2 Article 23 generally requires an early warning within 24 hours of becoming aware, an incident notification within 72 hours of becoming aware, and a final report within one month of the incident notification.
A useful shorthand is 24 → 72 → 1.
The NIS2 Article 23 early-warning clock starts when a covered entity becomes aware of a significant incident – not when the investigation is complete.
Identity exposure data can help security teams establish context early by revealing exposed credentials, session data, malware infections, and affected identities that may not be visible through internal security telemetry alone.
NIS2 and GDPR have different reporting requirements and triggers.
Under Article 31, NIS2 generally requires an early warning within 24 hours and an incident notification within 72 hours after becoming aware of a significant incident affecting network and information systems.
Under Article 33, GDPR generally requires notification to the relevant supervisory authority within 72 hours after becoming aware of a personal data breach, unless that breach is unlikely to result in a risk to individuals’ rights and freedoms.
An incident may trigger obligations under both frameworks depending on what occurred. For example – a ransomware attack that also exposes personal data means separate notifications to two different authorities on two different clocks.
For financial entities covered by the Digital Operational Resilience Act (DORA), DORA is the EU’s sector-specific framework for overlapping ICT risk-management and incident-reporting requirements. NIS2 Article 4 addresses how these equivalent sector-specific requirements interact with NIS2.
The exact requirements depend on the entity and activity involved, so financial organizations should assess the scope of DORA, NIS2, and applicable national rules rather than treating the frameworks as interchangeable. Organizations outside the financial sector that fall under one of NIS2’s 18 covered sectors follow NIS2 directly.
NIS2 Article 21(2)(d) requires covered entities to address supply chain security, including security-related aspects of their relationships with direct suppliers and service providers.
Continuous identity exposure monitoring can complement vendor assessments by identifying exposed credentials and authentication data associated with suppliers and contractors between point-in-time reviews.
Keep reading
