By NHI Mgmt Group Editorial TeamBased on Synack: “NIS2 is Live: Moving Beyond “Check-Box” Compliance to True Cyber Resilience” (December 16, 2025)

TL;DR: NIS2 now requires organisations to treat risk management, incident handling, supply chain security, and vulnerability disclosure as ongoing obligations rather than annual checks, according to Synack. The compliance challenge is no longer documentation alone; it is proving continuous operational resilience under stricter enforcement and reporting expectations.


At a glance

What this is: NIS2 is pushing regulated organisations toward continuous cyber resilience, with compliance now tied to ongoing risk management, incident handling, supply chain security, vulnerability disclosure and cryptography.

Why it matters: IAM, NHI and security teams have to prove that access, supplier, and vulnerability controls work continuously, not just at audit time.

By the numbers:

  • NIS2 compliance can carry penalties of up to €10M or 2% of global turnover.
  • Article 23(4)(a) requires an early warning to the CSIRT within 24 hours of becoming aware of a significant incident.
  • Synack says its Red Team includes 1,500+ expert researchers.

Context

NIS2 changes the compliance problem from a yearly attestation exercise into an ongoing resilience requirement. The directive expects organisations to manage risk continuously across incident handling, supplier oversight, vulnerability disclosure and cryptography, which makes point-in-time assurance insufficient for regulated environments.

This matters to identity programmes because access, third-party connectivity and machine identities are part of the same operational surface that NIS2 now expects organisations to govern continuously. If a team cannot show current control performance across users, workloads and suppliers, the compliance gap becomes an operational risk gap as well.


Key questions

Q: What breaks when NIS2 is treated as a checkbox compliance exercise?

A: The programme breaks at the point where controls are assumed to equal resilience. NIS2 asks whether you can contain damage, preserve services, and prove accountability when something fails. If access paths remain broad or privileged routes stay open, the organisation may be compliant on paper but still unable to limit an incident’s impact.

Q: Why does NIS2 create more accountability for third-party access and supplier risk?

A: Because regulated services often depend on external APIs, vendors and delegated credentials that can directly affect availability, confidentiality and reporting obligations. Under NIS2, that dependency is not someone else's problem. If the supplier path can harm your service, your governance model has to account for it.

Q: How do organisations know whether resilience controls are actually working?

A: They know by testing under failure conditions, not by checking configuration alone. A resilience control is working if the team can still reach critical credentials, restore service, and complete remediation when the main environment is down. If the process only works when production is healthy, it is availability theatre rather than resilience.

Q: What should organisations do when machine identities and shadow IT are outside inventory?

A: Treat them as ungoverned attack surface until proven otherwise. Unknown service accounts, tokens and externally facing assets cannot be risk assessed properly, remediated reliably or reported with confidence. The immediate priority is discovery, ownership and lifecycle control before those dependencies become accepted exposure.


Technical breakdown

Why continuous resilience replaces point-in-time testing

NIS2 pushes organisations away from annual assurance models because risk changes faster than audit cycles. Point-in-time penetration tests can show what was true on a given date, but they do not prove that exposure was reduced, that remediation was validated, or that new assets and dependencies were covered after the test. Continuous resilience means the control objective is not just finding flaws, but maintaining a live feedback loop between discovery, validation and response. That shift matters because compliance evidence must now reflect current security posture, not historical inspection.

Practical implication: Treat testing, validation and remediation as a continuous control loop, not a yearly compliance event.

Supply chain security as a governance control surface

NIS2 makes third-party risk a first-order concern because suppliers and external services can directly affect regulated services. The practical issue is that questionnaire-based assurance only captures stated controls, not the actual security condition of the dependency. For identity teams, this extends to delegated access, shared integrations and service credentials that connect internal systems to suppliers. Governance has to move from trust by declaration to evidence by verification, especially where external access paths can expand blast radius or create hidden accountability gaps.

Practical implication: Map every third-party integration and delegated access path to an owner, a review cadence and a verification method.

Attack surface discovery and machine identity visibility

NIS2 assumes organisations can see the assets they are responsible for, which is difficult when shadow IT, unmanaged web apps and ephemeral infrastructure appear faster than inventories are updated. That visibility problem also includes machine identities such as service accounts, API keys and tokens that may not sit in traditional IAM registers. Continuous discovery is therefore not just a network hygiene issue; it is a governance requirement for knowing what needs testing, who owns it, and whether credentials or access paths have become stale.

Practical implication: Build an always-current inventory of external assets and machine identities so new exposure is tested before it becomes accepted risk.


Threat narrative

Attacker objective: The attacker aims to turn weakly governed external dependencies into a path for service disruption, data exposure or compliance-triggering incidents.

  1. Entry occurs through an untested external asset, supplier integration, or vulnerable third-party API that sits outside a continuous validation cycle.
  2. Credential or access abuse follows when that exposed dependency gives an attacker a valid path into the regulated environment or its connected services.
  3. The impact is operational and regulatory, because the organisation must now handle incident reporting, supplier accountability and remediation under stricter enforcement.
  • Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
  • CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Continuous resilience is now the compliance model, not a maturity aspiration. NIS2 turns security evidence into an operational requirement because controls must work continuously rather than only at audit time. That changes the governance question from whether a control exists to whether it is producing current, defensible outcomes across live environments. The practitioner conclusion is that periodic validation no longer establishes readiness on its own.

Supply chain accountability has moved into the identity and access problem space. When suppliers, APIs and integrated services can affect regulated operations, their access paths become part of the compliance surface. That means delegated credentials, service accounts and third-party integrations need the same lifecycle discipline as internal access. The practitioner conclusion is that supplier governance now depends on access governance as much as on contract language.

Attack surface discovery is a resilience control, not just an inventory task. NIS2 assumes organisations can identify what needs protection and testing as change happens. Shadow IT, ephemeral infrastructure and unmanaged machine identities undermine that assumption because unknown assets cannot be validated or reported with confidence. The practitioner conclusion is that continuous discovery becomes the prerequisite for continuous compliance.

Live validation will outlast questionnaire-led assurance as the dominant trust model. Static attestations cannot prove that an external dependency, secret or exposed asset is still safe after the last review date. The stronger named concept here is compliance drift, the gap between documented controls and current operational reality. The practitioner conclusion is that evidence quality now depends on current-state verification, not paperwork alone.

What this signals

Compliance drift is the real NIS2 failure mode: the gap between written controls and the live state of suppliers, assets and credentials will now matter more than annual assurance artefacts. For identity and security teams, that means continuous verification has to sit inside operational workflows, not outside them.

NIS2 also pushes machine identity governance into the same conversation as third-party risk because unmanaged credentials can turn routine integrations into reportable incidents. Teams that cannot see service accounts, tokens and external dependencies in one control view will struggle to prove resilience under enforcement pressure.


For practitioners

  • Build continuous validation for regulated controls Replace annual-only testing with an operating model that rechecks exposed assets, critical dependencies and remediated findings on a rolling basis.
  • Inventory third-party access paths and owners Document each supplier integration, API dependency and delegated credential, then assign ownership for review, escalation and offboarding.
  • Extend discovery to machine identities Track service accounts, tokens, API keys and certificates alongside human access so unmanaged credentials do not escape governance.
  • Align incident evidence with reporting deadlines Make sure detection, validation and escalation workflows can support early-warning obligations and produce evidence quickly enough for regulatory reporting.

Key takeaways

  • NIS2 turns compliance into an operational discipline, with live resilience now more important than periodic attestations.
  • Third-party integrations, supplier APIs and machine identities now sit inside the governance perimeter because they can create reportable risk.
  • Continuous discovery, validation and escalation are the controls that determine whether organisations can prove readiness under NIS2.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.RM-01 — Risk Management StrategyNIS2's continuous resilience model is fundamentally about risk governance and ongoing control assurance.
PR.DS-01 — Data-at-Rest ProtectionThe article explicitly cites cryptography as part of the ongoing technical measures NIS2 expects.
DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices and SoftwareContinuous attack-surface discovery and live validation depend on ongoing monitoring of assets and connections.
Recommendation — Embed continuous risk monitoring into your governance model so compliance evidence stays current. Review cryptographic protections and key handling so data controls support continuous compliance. Use continuous monitoring to keep external assets, suppliers and unexpected connections visible.
NIST SP 800-53 Rev 5RA-5 — Vulnerability Monitoring and ScanningThe article centres on continuous vulnerability discovery and validation rather than annual review.
SR-6 — Supplier Assessments and ReviewsNIS2 places supplier security and third-party accountability inside the regulated perimeter.
Recommendation — Increase vulnerability scanning cadence and verify remediation with repeatable validation. Formalise supplier security reviews so third-party risk is continuously reassessed.

Key terms

  • Continuous Resilience Validation: Continuous Resilience Validation is the practice of automatically testing whether identity recovery actually works before an incident occurs. It turns recovery from a theoretical plan into a verified capability by exercising rollback, failover, and restoration paths and producing auditable proof for assessors and operational leaders.
  • Compliance Drift: Compliance drift is the gap between what a policy says, what the procedure requires, and what the organisation actually does. It usually appears when ownership is unclear, version control is weak, or evidence is collected too late to prove control operation.
  • Attack Surface Discovery: The process of finding and classifying assets that can be reached, tested, or abused by an attacker. In modern AppSec, discovery must be continuous because build pipelines, AI-assisted code, and microservice sprawl can change the attack surface faster than manual review can track.
  • Supplier Security Assessment: Supplier security assessment is the process of evaluating the controls, vulnerabilities, and overall risk presented by direct suppliers. It helps organisations avoid treating third-party risk as a generic checkbox exercise. Under frameworks like NIS2, it supports informed control selection, oversight, and gap analysis across the supply chain.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps identity and security practitioners build the control foundations needed for programmes that now depend on continuous verification.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org