Back to blog
·NIS2 Compliance

NIS2 Detection Compliance: What Your SIEM Won't Tell You

NIS2 requires European companies to detect and report incidents within 24 hours. Most SIEMs fail this test. Here's why deception technology changes the equation.

The NIS2 Directive came into force across the EU in October 2024. Article 23 is the one that keeps CISOs up at night: significant incidents must be reported within 24 hours of detection.

Not 24 hours after breach. 24 hours after detection.

Most companies are not measuring detection time. They're measuring breach time — the moment an attacker accessed a system. The gap between breach and detection (the "dwell time") averages 197 days in Europe according to IBM's 2024 Cost of a Data Breach report.

197 days vs. 24 hours. That's the compliance problem.

Why Traditional SIEMs Struggle with NIS2 Detection Requirements

SIEMs are built on a fundamentally flawed assumption: that you can find attackers by looking for anomalies in a sea of legitimate activity.

The result is alert fatigue. The average enterprise SIEM generates 10,000+ alerts per day. Security teams triage perhaps 5% of them. Attackers who move slowly and quietly — using legitimate credentials, avoiding unusual traffic patterns — simply don't show up.

This is exactly the behaviour of a sophisticated threat actor. And under NIS2, missing it has regulatory consequences.

The Deception Approach: Zero False Positives by Design

Deception technology works differently. Instead of watching for anomalies in real traffic, you plant honeytokens — fake credentials, URLs, documents, and database connections that have no legitimate use.

The logic is simple: no legitimate user ever touches a honeytoken. If something triggers one, it's an attacker. No tuning, no thresholds, no analyst review needed.

For NIS2, this is transformative:

  • Detection time: seconds, not days — the moment a honeytoken is touched, you have an alert
  • Zero false positives — every alert is a confirmed threat
  • Documented evidence — timestamped logs of attacker behaviour for the 24h NIS2 report

What a NIS2-Compliant Detection Event Looks Like

When a Vantuz honeytoken is triggered, the AI investigation pipeline runs automatically:

  1. T+0ms — Token triggered (attacker uses fake AWS key, visits URL, opens PDF)
  2. T+3s — Attacker IP enriched: geolocation, abuse score, open ports
  3. T+5s — Risk score calculated (0–100, deterministic — no hallucination risk)
  4. T+8s — MITRE ATT&CK techniques mapped based on token type and behaviour
  5. T+30s — Containment executed if score exceeds workspace threshold
  6. T+60s — Claude generates executive incident summary for CISO

The output is a PDF compliance report you can attach to your NIS2 notification — with attacker profile, evidence chain, timeline, and containment actions taken.

The Three Honeytoken Types with the Highest NIS2 ROI

Not all honeytokens are equal for compliance purposes. These three generate the most actionable evidence:

AWS Credential Honeytoken

A real IAM key attached to a user with zero permissions. Any API call triggers a CloudTrail event, which routes to your Vantuz workspace. Best planted in: GitHub repositories, .env files in developer machines, internal documentation.

Why it's NIS2-relevant: cloud credential theft is the most common initial access vector in EU mid-market breaches. Detection happens instantly at first use — not 197 days later.

PDF Honeytoken

A document with an embedded tracking element that fires when opened in Adobe Acrobat or any compliant PDF reader. Best planted in: board decks, M&A documents, HR files, client contracts.

Why it's NIS2-relevant: data exfiltration of sensitive documents is exactly what NIS2 Article 6 considers a "significant incident". This gives you proof the moment a document is accessed outside your control.

Database Credential Honeytoken

A fake PostgreSQL/MySQL connection string that alerts on any connection attempt. Best planted in: deployment scripts, code repositories, developer notes.

Why it's NIS2-relevant: database access is the goal of most breaches. Detecting the credential being used — before any data is actually exfiltrated — gives you NIS2 detection compliance with time to respond.

Practical Implementation: What to Do This Week

You don't need to wait for a full security audit to start. Three honeytokens, planted in the right places, give you immediate NIS2 detection capability:

  1. Create an AWS honeytoken → plant the key in your most-forked internal repository
  2. Create a URL honeytoken → embed it in your most-sensitive internal PDF or wiki page
  3. Create a DB credential honeytoken → add it to your main deployment configuration

Connect your alert email. Set your risk threshold. You now have a 24-hour incident detection capability that satisfies NIS2 Article 23.

The goal is not to replace your SIEM. It's to guarantee that the attacks your SIEM misses — the slow, credential-based, legitimate-looking ones — are caught before your 24-hour clock runs out.

Vantuz is an AI deception security platform built for European companies facing NIS2. Get started free →