NIS2 — Directive (EU) 2022/2555

Support selected NIS2 controls with verifiable approval evidence.

Article 20 requires management bodies to approve cybersecurity risk-management measures and oversee their implementation. Article 21 lists the measure categories. INTYGA can implement and evidence a narrow part of several categories — most directly authorization and step-up for privileged actions. A signature does not answer an entire NIS2 measure by itself.

Start free Start with an assessment instead

Governance needs evidence a reviewer can check

The Directive says management bodies can be held liable for an entity's Article 21 infringements, subject to applicable national liability rules. It does not require a named operational approver for every change. An INTYGA receipt can show which eligible human approved one exact action and let a third party verify the signature without trusting INTYGA.

That receipt can support evidence that a configured approval control operated. It does not prove that the management body approved the entity's cybersecurity measures or oversaw the wider programme.

Article 21 controls INTYGA can support

Access-control policies — strongest mapping

A protected action is inert until an eligible human or quorum approves its exact parameters. This can implement and evidence authorization, separation of duties and privileged-action approval. It does not provide your access-control policy, identity lifecycle or periodic access review.

MFA and step-up authentication — conditional mapping

INTYGA requires WebAuthn user verification for each approval and can require an allowed authenticator class. ENISA recommends re-authentication or step-up before privileged access and allows MFA to be required for high-risk actions. Whether a deployment satisfies MFA depends on its factor and authenticator configuration. This is not continuous authentication, which assesses changing risk throughout a session.

Policies and procedures on cryptography — narrow support

Approval receipts use ES256 with key type and curve checked, and INTYGA holds no private key capable of producing an approval. Synced passkeys are supported unless your policy requires a hardware-bound authenticator. The product does not establish your cryptography policy, key lifecycle or crypto-agility process.

Supply chain security — third-party access slice

INTYGA can place your authorization gate in front of a supplier-originated automated action. Supplier selection, contracts, vulnerability handling, monitoring, audit rights and your supplier directory remain separate controls.

Incident handling — supporting evidence

Tamper-evident approval, authentication and rejection records can support monitoring and investigation. INTYGA does not provide incident classification, response, recovery, communications, exercises or post-incident review.

Assessing effectiveness — one-control input

Discovery Mode records eligible requests routed through INTYGA without requiring human approval; other security checks still apply. The Runtime Assessment can evaluate the configured authorization and separation-of-duties control within that traffic; it does not assess your full cybersecurity risk-management programme.

Where the mapping stops

Your obligations do not transfer to INTYGA. Buying a control does not discharge them, and nothing here makes an organization NIS2-conformant. A vendor may also be in scope in its own capacity.

Parts of six categories; no category in full. INTYGA does nothing for business continuity and backups, nothing for cyber hygiene and training, and touches acquisition and development security only through its own practices.

It produces no incident notifications. For a significant incident, Article 23 requires notification without undue delay and, in any event, an early warning within 24 hours and an incident notification within 72 hours of awareness. INTYGA can provide only part of the record behind them.

Sector scope matters. Regulation 2024/2690 and ENISA's guidance directly address the digital and ICT entities named in that regulation. Energy and other sectors must use their national and sector-specific requirements. In Sweden, the Cybersecurity Act has applied since 15 January 2026; MCFFS 2026:11 applies from 1 October 2026 where relevant.

This mapping is source-checked, not legally reviewed. It was checked on 17 August 2026 against the Directive, Regulation 2024/2690 and ENISA's guidance. It is technical analysis, not legal advice or an attestation.

Primary sources

Read the official NIS2 Directive, Implementing Regulation (EU) 2024/2690, ENISA technical guidance, Swedish Cybersecurity Act (2025:1506) and MCFFS 2026:11.

Find out where the gaps are before you commit to closing them.

The Runtime Assessment observes eligible requests routed through INTYGA without requiring human approval, and reports potential control gaps in that traffic. Other security checks still apply; workflows outside the integration are not measured. Start with a defined coverage boundary.

See the other framework mappings →