Cyber decoys for defenders: what CISA's new guidance actually says

The perimeter falls. That is not a pessimistic assumption — it is the premise every Zero Trust model starts from: assume an attacker will, at some point, gain some level of access inside. The question that matters is no longer whether they get in, but how fast you find out. And this is where most organisations do badly: dwell time — the gap between compromise and detection — is still measured in weeks, not because the attack is subtle, but because nothing on the network is put there specifically to be touched by mistake.

On 16 September 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) published guidance aimed squarely at this problem: Using Cyber Decoys to Strengthen Detection and Response (TLP:CLEAR). It is an introductory resource, written for small and medium-sized organisations and for defensive teams new to deception. It is worth reading because it normalises an idea still treated as “exotic” in many SOCs: decoys are not a luxury for mature teams, but a cheap, incremental detection mechanism with a very clean signal.

We walk through what the guidance says and, at the end, show where it connects directly to our work.

What decoys actually are

A decoy (or lure) is an asset that looks legitimate — a system, an account, a file, a set of credentials — but has no real operational purpose. It is placed there for one reason: nothing legitimate has any business touching it. Therefore the first touch is, by definition, suspicious.

CISA uses precise vocabulary, adapted from the MITRE Engage glossary:

• Decoys (lures) — assets that appear to be legitimate systems, accounts or data, but are designed to distract adversaries, detect their presence or help collect cyber threat intelligence (CTI).
• Tripwires — decoys configured so that any interaction (access, authentication attempt, command execution) generates an alert. Any decoy becomes a tripwire once it is wired into monitoring and alerting.
• Breadcrumbs — decoy artefacts placed deliberately for adversaries to follow, leading them toward other decoy assets or controlled environments.

The document draws a clear line between two families of decoy, side by side:

Attribute	Honeypot	Honeytoken
Level of operation	system / network	data / asset
What it is	decoy system or service, often with intentional vulnerabilities	data item with no legitimate purpose, placed among real assets
Complexity	medium to high	low
Maturity required	high	low
Examples	servers, databases, web pages, clients	files, records, accounts, credentials, email addresses, fake URLs

The distinction matters operationally. A honeypot is a whole system you maintain and isolate — it costs time and discipline. A honeytoken is a poisoned strand of data you seed among the real ones — it deploys quickly, at low maturity, and produces exactly the same high-value signal: someone touched something they had no reason to touch.

Why it works: signal, not noise

A SOC’s classic problem is not a shortage of alerts, but a flood of them. Behaviour- and signature-based detection produces thousands of events a day, many of them false positives. Analysts triage the loudest, not necessarily the most important, and burn out. And living off the land (LOTL) techniques — the attacker using the system’s native tools and valid credentials — look exactly like normal administration. There is no anomaly to detect.

Decoys flip the logic. CISA notes that decoy-based Expose operations:

• generate high-fidelity alerts representing behaviour with little or no legitimate use;
• reduce noise, because interactions with a decoy should be rare in normal operations;
• give earlier and clearer indications of compromise, reducing mean time to detection (MTTD).

The key is that the value does not come from an algorithm’s promise of accuracy, but from a property of the environment: if a file, an account or an API key has no legitimate user, any interaction with it is, by construction, an indicator. The document stresses that decoys are especially valuable against LOTL techniques, where classic signature-based approaches struggle.

The framework: MITRE Engage and ATT&CK

The guidance does not encourage improvisation. It structures everything on MITRE Engage — a framework for planning, implementing and assessing adversary-engagement activities — and on the MITRE ATT&CK knowledge base, which describes adversary tactics and techniques.

Engage groups goals into three categories:

• Expose — detect adversaries operating in the environment. This is where most of the quick wins sit: decoys placed where legitimate users should never go, configured to produce high-fidelity alerts.
• Affect — impose cost on the adversary: divert them toward decoy systems, poison their reconnaissance with fake accounts and services, make them waste time on worthless data.
• Elicit — observe the adversary in a controlled, realistic environment to collect high-value CTI about their TTPs.

The sequencing advice is clear and honest: Expose first, then Affect where it makes sense; Elicit comes last, because it requires realistic but isolated environments, mature monitoring and staff able to manage the operational and legal risks. Don’t skip the rungs.

On top of this, Engage describes a 10-step process across three phases — Prepare, Operate, Understand — from assessing your knowledge of the adversary and of your own organisation, through to analysing the successes and failures that feed the next operation. The underlying idea: deception is not a project with an end, it is a cycle.

Honeytoken types, and where to source them

Because honeytokens have the lowest barrier to entry, the guidance details them. Any asset that looks legitimate and might interest an attacker can be a honeytoken:

• Files and documents that appear to hold sensitive information and raise alerts when opened, copied or modified.
• Data records — fake entries placed next to real ones; accessing them signals unauthorised exploration or data theft.
• Accounts that are disabled or unused; any authentication attempt is suspicious.
• Credentials — fake passwords, API keys or tokens stored in controlled locations; using them indicates a compromise and helps identify where they were stolen.
• Email addresses used as decoys, placed in directories or applications; an email sent to them indicates unauthorised access to the underlying store.
• Web-based artefacts — decoy URLs or links with no business purpose; a request to them raises an alert.

An effective strategy, CISA says, deploys multiple token types and places them in multiple locations (key servers, workstations, cloud repositories, identity systems), guided by CTI and by likely attack paths. Diversity raises the odds that an attacker who bypasses one set of controls triggers another — and helps defenders infer the adversary’s objectives and movement from which tokens were touched.

For sourcing, the document lists four approaches without favouring any vendor: open-source solutions (good for pilots and tight budgets), commercial solutions (centralised management, reporting, support), homegrown implementations (tailored to the environment, for teams with development capacity) and LOTL approaches — using tools you already have (EDR, IAM, DLP) to deploy and monitor decoys without buying new tooling.

How to plan it properly: ATT&CK, gap analysis, purple team

The most useful part of the guidance is not the list of decoys, but the method for deciding where to put them. CISA describes a process that overlays three ATT&CK maps:

1. Your vulnerabilities — which tactics and techniques apply, given your environment and configurations.
2. Your defensive coverage — what you already detect (EDR, SIEM, segmentation, IAM, SOAR) and where the gaps are.
3. Adversary capabilities — the TTPs used by the actors likely to target you, from CTI and past incidents.

Overlaying them surfaces the high-risk gaps: techniques for which you are vulnerable, adversaries operate, but detection is weak or absent. That is where the decoys go. In the guidance’s scenario — a water and wastewater organisation — the analysis surfaces clear gaps around phishing, PowerShell execution (LOTL) and exfiltration to cloud backups, and the decoys are designed against exactly those techniques (fake low-privilege accounts, services on decoy ports, sensitive command tokens on workstations).

And, crucially: once you plant them, you test. The guidance calls for threat emulation, red teaming or purple teaming using relevant ATT&CK techniques, to verify that decoys actually trigger and that alerts reach defenders and are handled in time. A decoy that does not produce a visible, actionable alert is just one more file. Deception is validated, not assumed.

Where this connects to Vigilum

All of this guidance describes, in public-policy terms, exactly the principle Vigilum is built on — our deception-based intrusion detection platform: you plant credible decoys in your infrastructure, you wait, you find out. No legitimate process has any reason to touch them, so the first touch is, by definition, an intruder.

A few points where CISA’s recommendations and the way we work line up naturally:

• Expose, first. Vigilum is centred on the Engage goal with the best effort-to-signal ratio: detection, with high-confidence alerts. Less noise, more certainty.
• Decoys tailored to the environment, not a template. The guidance insists decoys must be plausible and threat-informed. Vigilum generates decoys for your specific environment — your naming conventions, your stack, your topology — not one identical set for every client. A decoy that doesn’t fit the environment never gets touched.
• Lateral movement with attribution. The hard case in the guidance — the attacker with valid credentials who “looks like an admin” — is precisely the one decoys solve: you are not hunting for an anomaly, you are waiting for a touch that has no legitimate explanation.
• On-prem or airgap. The document recommends keeping decoy documentation outside the production environment and having deception work in isolated networks. Vigilum runs in your own rack, including fully disconnected.
• Validation through purple team. The emulation step in the guidance is the very service we have been doing for twenty years: we test that decoys trigger and that the response works, using real ATT&CK techniques. Tools cut the dead time; judgment stays with the tester.

Vigilum is in Early Access — we open access gradually, for teams that want to move from “we assume we’re compromised” to “we find out in minutes, not weeks”. If the CISA guidance confirmed a hunch you already had, let’s talk about what deception looks like in your infrastructure.

Instead of a conclusion

Decoys do not replace EDR, SIEM or segmentation. They complement them, in a place where those struggle: post-compromise, against the attacker using legitimate tools and stolen credentials. The merit of CISA’s guidance is that it says this plainly and lowers the barrier to entry — with honeytokens, any team can start tomorrow, incrementally, without rewriting its architecture.

And the underlying principle is as sober as it gets: you don’t try to guess what’s bad. You put a few things on the network that nothing good has any reason to touch — and you wait for the first touch.

---

Source: Cybersecurity and Infrastructure Security Agency (CISA), “Using Cyber Decoys to Strengthen Detection and Response”, 16 September 2026 (TLP:CLEAR). Reference frameworks: MITRE Engage™ and MITRE ATT&CK®.