Book an Appointment

Honeypots & Deception

How honeypots, honeytokens and deception platforms help you detect attackers inside your internal network early – with high signal quality and, by design, very few false positives.

Attackers who have breached perimeter and endpoint defenses often move through internal networks undetected for long periods. Deception technologies address exactly this gap: decoy systems (honeypots), planted data and credentials (honeytokens), and centrally orchestrated deception environments that serve no purpose whatsoever for legitimate users. Because nobody has a reason to touch these resources, virtually every interaction is a reliable attack signal – the number of false positives is inherently low by design. This article puts the different variants into perspective, along with sensible placement, the legal situation in Germany, and the limitations and operational effort involved.

The Essentials at a Glance

01

Low- vs. High-Interaction Honeypots

Honeypots are systems with no productive purpose whose sole job is to be attacked – which makes every interaction at least suspicious by definition. Low-interaction honeypots emulate individual services or protocols only superficially; they are resource-efficient, quick to deploy and low-risk, but provide limited insight and are easier for attackers to identify as decoys. High-interaction honeypots run real operating systems and applications and allow deep analysis of attacker tools and techniques – at the cost of significantly higher operational and hardening effort. In its foundational study, ENISA evaluated 30 honeypot solutions along exactly this taxonomy, covering both server-side and client-side variants.

02

Honeytokens and Canaries

Honeytokens transfer the decoy principle from systems to data and credentials: planted API keys, documents, database records, DNS names or email addresses that nobody uses in regular operations. If such an object is opened or a planted key is used, this constitutes an almost unambiguous indicator of compromise – even where traditional sensors are absent, for example in SaaS services or in cases of data exfiltration. Freely available services such as Canarytokens by Thinkst offer more than 30 token types, from AWS keys and Office documents to kubeconfig files, enabling adoption with minimal effort. NIST describes this approach (“tainting”), alongside redirecting attackers (“misdirection”), as an approach within the cyber resiliency technique of deception.

03

Deception Platforms in the Detection Stack

Traditional detection via SIEM, EDR or NDR has to filter attacks out of vast volumes of legitimate events – with the corresponding background noise and tuning effort. Deception inverts this logic: since legitimate users never touch decoys and honeytokens, virtually every alert is relevant. Deception platforms orchestrate decoys centrally, feed alerts into the SIEM or SOC, and deliver context-rich telemetry for incident response. Since 2022, MITRE Engage has also provided a dedicated framework that structures denial, deception and adversary engagement activities and aligns them with attacker behavior observed in the real world. For operators of critical facilities, deception can complement the attack detection systems required under Section 31 BSIG – but it cannot replace them.

04

Sensible Placement

Deception is effective where attackers move after initial access: in internal network segments, in Active Directory, on file and backup systems, in cloud environments and increasingly in OT networks as well. Proven practice includes deploying decoy systems in every relevant segment and placing honeytokens in repositories, configuration files and credential stores – along the paths that lateral movement and privilege escalation typically take. A honeypot publicly exposed on the internet, by contrast, mainly generates background noise from mass scanning and contributes little to detecting targeted attacks on your own network. Credibility is decisive: naming conventions, patch levels and metadata of the decoys must match the real environment, and deception infrastructure must be strictly separated from the production network.

05

Legal Assessment in Germany

Operating honeypots on your own infrastructure is permissible as a pure detection measure – the attacker accesses the operator's systems of their own accord, which does not constitute criminal “incitement”. This must be clearly distinguished from the “hack back”: active access to third-party systems is not permitted for companies in Germany and remains a criminal offense in the absence of a legal authorization (including under Sections 202a et seq. of the German Criminal Code, StGB); deception ends at your own network boundary. Under data protection law, the processing of the data generated in the process (such as IP addresses) can regularly be based on legitimate interest under Art. 6(1)(f) GDPR – Recital 49 explicitly mentions ensuring network and information security, insofar as the processing is strictly necessary and proportionate for that purpose. Care is required in the scenario where a compromised high-interaction honeypot is abused as a stepping stone for attacks on third parties: criminal law literature discusses aiding-and-abetting risks for operators in this context, which is why outbound traffic must be strictly restricted at the technical level.

06

Limitations and Operational Effort

Deception only detects attackers who actually interact with decoys – it replaces neither prevention nor comprehensive detection, but complements both with a highly precise additional signal source. Experienced attackers attempt to unmask honeypots through fingerprinting; emulation artifacts, implausible systems or missing traces of use destroy the illusion and devalue the measure. Operating deception therefore requires ongoing care: updating decoys, adapting to changes in the environment, defined playbooks for alerts and clear responsibilities within the SOC. The ENISA study already identified usability, documentation and staffing requirements as major hurdles to honeypot adoption – modern platforms and honeytoken services lower this threshold considerably, but do not eliminate the maintenance effort entirely.

Standards & Sources

The content on this page is based on the following publicly available guides and studies.

ENISA · 2012

Proactive Detection of Security Incidents II – Honeypots

Foundational study evaluating 30 honeypot solutions along the low-/high-interaction taxonomy (server-side and client-side), including the hurdles to deployment.

MITRE · 2022

MITRE Engage v1.0

Framework for planning denial, deception and adversary engagement activities; successor to MITRE Shield, released in spring 2022.

NIST · 2021

NIST SP 800-160 Vol. 2 Rev. 1: Developing Cyber-Resilient Systems

Describes deception as a cyber resiliency technique with the approaches misdirection (diverting attackers into controlled environments) and tainting (marked resources).

Thinkst · 2026

Canarytokens Documentation

Documentation of the free honeytoken service with more than 30 token types, including cloud keys, Office documents and DNS-based triggers.

KriPoZ – Kriminalpolitische Zeitschrift · 2024

Research Honeypots – Strafbarkeitsrisiken für IT-Sicherheitsforschende?

Legal analysis of criminal liability risks in honeypot operation, including the aiding-and-abetting issue when a honeypot is abused as a stepping stone for attacks.

Bundesministerium der Justiz / gesetze-im-internet.de · 2025

Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG)

Section 31 BSIG obliges operators of critical facilities to deploy state-of-the-art attack detection systems; version following the NIS2 transposition.

Ready to integrate deception into your detection strategy?

We work with you to assess where honeypots and honeytokens deliver the greatest detection gain in your environment – vendor-neutral, legally sound and integrated into your SOC. Talk to us.