NIS2 & EU AI Act
The opensecstack ecosystem is designed around the European regulatory and threat landscape. This page maps how the 11 platforms satisfy the security measures mandated by NIS2 Directive 2022/2555 (Articles 21 and 23) and explains the additional obligations introduced by the EU AI Act (Regulation 2024/1689), which intersect with VertGuard and the projected NIS3 trajectory.
Overview
NIS2 applies to essential and important entities across the EU. It mandates appropriate technical and organisational security measures (Article 21) and requires notification of significant incidents to the national CSIRT or competent authority within defined deadlines (Article 23). The opensecstack ecosystem was built to provide a complete, evidence-generating, self-hostable implementation of these obligations.
No single platform covers every measure. The ecosystem is designed so each platform is the primary evidence source for one or two measures, with secondary contributions across others. The combination of platforms — particularly the CITADEL WORM audit chain and NIS2 Compass as the assessment hub — means auditors can trace every control back to tamper-evident, independently verifiable records.
nis2-mapping.md (in its docs/ folder) provides the full per-measure evidence package and configuration steps for that platform.Article 21(2) measures
Article 21(2) lists ten categories of security measure that essential and important entities must implement:
| Ref | Measure |
|---|---|
| (a) | Risk analysis and information system security policies |
| (b) | Incident handling |
| (c) | Business continuity and crisis management |
| (d) | Supply chain security |
| (e) | Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure |
| (f) | Policies and procedures to assess the effectiveness of cybersecurity risk-management measures |
| (g) | Basic cyber hygiene practices and cybersecurity training |
| (h) | Policies and procedures regarding the use of cryptography and encryption |
| (i) | Human resources security, access control policies and asset management |
| (j) | Use of multi-factor authentication or continuous authentication solutions |
Platform coverage table
The table below maps each platform to the measures it primarily covers and any secondary contributions. Primary means the platform generates the main compliance evidence for that measure. Secondary means the platform contributes supporting evidence but is not the main record.
| Platform | Primary measure(s) | Secondary measures | Notes |
|---|---|---|---|
| NIS2 Compass | (a) (b) (c) — all measures (assessment hub) | All | Central compliance evidence store; integrates evidence from all other platforms and manages Art. 23 notification records |
| IRFlow | (b) Incident handling | (a) (c) (d) (e) (f) (h) (i) (j) | Core incident lifecycle; WORM-anchored timeline; auto-notifies NIS2 Compass within 24-hour window for P1/P2 incidents |
| APIGuard | (e) Vulnerability handling | (a) (d) (h) (i) (j) | OWASP API Top 10 coverage; scan reports constitute technical evidence for Art. 21(2)(e); CI/CD integration via SARIF export |
| ThreatFlow | (b) (d) (e) | (h) | IOC enrichment for incidents; STIX 2.1 exports for NIS2 Compass; tracks supply-chain IOCs; monitors cryptographic vulnerability indicators |
| OpenScrub | (b) (c) Availability & DDoS response | (a) (e) | XDP/eBPF DDoS mitigation; emits structured events to CITADEL ARBITER for Art. 23 aggregation on High/Critical attack events |
| VertGuard | (e) AI-attack defence | (a) (b) (d) (f) (h) | Prompt injection, deepfake, synthetic identity, AI phishing detection; MITRE ATLAS categorisation; WORM-anchored detections; also maps to EU AI Act |
| OpenCSIRT | (b) CSIRT operations | (d) (e) | TAXII 2.1 / CSAF 2.0; peer federation; Art. 23 notification support; WORM emission on advisory publication |
| CyberPath | (g) Cyber hygiene & training | (b) | Docker/Wasm security labs; generates training completion records usable as Art. 21(2)(g) evidence |
| SecureLab | (f) Effectiveness assessment | (b) (e) | Attack simulation and detection validation; scenario results feed effectiveness metrics |
| CITADEL | (h) Cryptography; (i) Access control | All (governance layer) | MARSHAL 5-gate policy engine; WORM audit chain with TripleHash integrity (SHA-256 + SHA-512 + BLAKE3) and Ed25519 anchors; SoD enforcement across all platforms |
| sinauth | (j) MFA & authenticated access | (i) | OAuth 2.0 / OIDC; PKCE; RS256 + JWKS; TOTP MFA; single sign-on for all platform operators |
Article 23 notification
Article 23 requires essential entities to notify the national CSIRT or competent authority of significant incidents within strict deadlines. The ecosystem automates the 24-hour early-warning path for the highest-severity incidents.
| Phase | Deadline | Ecosystem feature |
|---|---|---|
| Early warning | 24 hours after becoming aware | IRFlow auto-pushes to NIS2 Compass /api/v1/notifications on creation of any P1/P2 incident. The notification runs on a detached goroutine so a slow Compass API never blocks incident creation. |
| Full notification | 72 hours | Manual today; IRFlow v1.1 adds an upgrade-notification path that resubmits the incident timeline. OpenScrub emits severity High/Critical attack events to CITADEL ARBITER for aggregation. |
| Final report | 1 month | NIS2 Compass assessment export. IRFlow and ThreatFlow records are referenced as evidence artefacts. |
ThreatFlow also participates in the 24-hour path: when IOC correlation raises a P1/P2 incident above NIS2 significance thresholds, ThreatFlow sets the nis2_notify_required flag on the IRFlow incident via the incidents API, triggering the same notification goroutine.
A successful notification records nis2_notified_at on the IRFlow incident row. The metric irflow_governance_calls_total{target="nis2",result="failure"} surfaces notification failures for operator alerting.
EU AI Act — VertGuard
The EU AI Act (Regulation 2024/1689) entered force in August 2024 with staggered applicability through 2027. It applies to VertGuard in two ways:
- VertGuard as AI system operator (low-risk tier): VertGuard itself uses ML for Modules 1, 2, and 5. This makes it an AI system with obligations under the Act.
- VertGuard as a defence tool for AI system operators: Organisations deploying LLM-powered applications are themselves AI Act-scoped. VertGuard provides the technical controls for prompt-injection blocking (Art. 14 human oversight), detection logging (Art. 12 record-keeping), and AI-attack defence (Art. 15 cybersecurity).
| EU AI Act article | Obligation | VertGuard compliance |
|---|---|---|
| Art. 9 | Risk management system | Documented in SECURITY.md threat model; Module 3 implements the runnable policy |
| Art. 10 | Data governance | Model + dataset registries with provenance and SHA-256 checksums |
| Art. 11 | Technical documentation | Full model cards in docs/ml-models-reference.md |
| Art. 12 | Record-keeping (logging) | All detections WORM-logged via CITADEL from v0.1 |
| Art. 13 | Transparency | Per-detection confidence exposed; deterministic patterns separated from ML classification; C2PA signer chain exposed per detection |
| Art. 14 | Human oversight | Prompt-injection blocking + appeals process via CITADEL MARSHAL gate |
| Art. 15 | Accuracy, robustness, cybersecurity | Published accuracy benchmarks; false-positive test corpus; Module 3 is the primary AI security control |
NIS3 readiness (projected)
NIS3 does not yet exist as a formal instrument. Based on NIS2 Article 41's review schedule, the Commission will publish a review by October 2027; a legislative proposal is plausible for 2028–2029, with adoption 2030–2031 and transposition 2032–2033.
NIS3 is expected to move beyond NIS2's generic "network and information systems security" language and introduce explicit obligations for AI-attack defence, AI supply-chain provenance, cross-CSIRT AI-threat sharing, and post-quantum cryptographic migration. The following table shows where the ecosystem stands today against projected NIS3 requirements:
| Projected NIS3 requirement | VertGuard / ecosystem today | Status |
|---|---|---|
| AI-system input attack defence (prompt injection, jailbreaks) | Module 3 — pattern + ML classifier (Phase 4.1/4.2) | Covered |
| Deepfake / synthetic media detection | Module 1 — C2PA in v0.1; ML deepfake in v0.5 (2027) | Partial |
| AI-generated phishing detection | Module 2 — planned v0.5 (2027 Q3) | Planned |
| ML supply-chain provenance (model + dataset) | Model registry + SHA-256 checksums; dataset registry | Partial |
| Cryptographic evidence chain (tamper-evident) | TripleHash + CITADEL WORM + Ed25519 anchor signatures | Covered |
| Standardised AI-IOC format (STIX + MITRE ATLAS) | ThreatFlow STIX-compatible bundle; Module 4 ATLAS tagging | Covered |
| Post-quantum cryptographic migration mandate | Ecosystem PQ roadmap: hybrid Ed25519 + ML-DSA in v2.0 (2028); PQ-default in v3.0 (2030) | Planned |
| AI-agent governance (human oversight, audit trail) | CITADEL MARSHAL gate; every AI-initiated action reviewable | Partial |
| Cross-CSIRT AI-threat sharing | Module 4 ATLAS-tagged IOCs via ThreatFlow; OpenCSIRT federation Phase 3 (not yet implemented) | Partial |