CISA Just Put Decoys in the Baseline Playbook: What the Guidance Says and How to Apply It

For years, deception was treated as the security team's expensive toy: interesting in a conference talk, hard to defend in a budget meeting. On September 16, 2026, CISA published Using Cyber Decoys to Strengthen Detection and Response (TLP:CLEAR), and that changed the conversation. This is not a research paper or a trend piece. It is introductory guidance aimed explicitly at small and medium-sized organizations and at teams new to decoy operations, built around low-complexity steps.

When the agency that writes the critical infrastructure advisories says decoy techniques are "incremental, cost-effective, and scalable" and can be introduced without major architectural changes, the question is no longer whether they are worth it. The question is where you put the first tripwire.

TL;DR CISA frames decoys as the natural companion to Zero Trust: if you assume compromise, you need to detect whoever is already inside. The primary goal is not to fool anyone. It is to generate high-fidelity alerts and cut MTTD. The guidance uses MITRE Engage (Expose / Affect / Elicit) and ATT&CK as a planning method, not as decoration. Start with Expose. Honeytokens are rated low complexity, low required maturity. Elicit comes much later.

Why this guidance matters more than it looks

Most detection documents ask you for more: more logs, more rules, more analysts. This one runs the other way. It opens with three problems every SOC recognizes on sight:

High alert volumes, many of them false positives.
Limited analyst capacity, and the alert fatigue that follows.
Difficulty detecting stealthy, post-compromise activity, especially when the adversary uses native tools and legitimate credentials (living off the land).

CISA's argument is that a well-placed decoy hits all three at once, because interacting with a decoy has no legitimate business use. You do not have to correlate anything to know something is wrong. It is the difference between a smoke alarm and a sensor that reports the temperature every minute so you can decide whether there is a fire.

That is the point no vendor managed to land in a decade, and that a public document lands in two pages: decoys do not add noise, they replace it.

One scoping note worth catching: the document focuses on decoys deployed inside your environment (internal networks, systems, and services), not on the classic internet-facing honeypot. This is internal detection guidance, not botnet research.

Expose, Affect, Elicit: three goals, not three fashion tiers

MITRE Engage groups engagement operations into three goals, and CISA orders them by actual difficulty.

Expose: detect adversaries already operating in the environment. You get there by placing decoys where legitimate users should rarely or never interact with them, and configuring them to produce high-fidelity alerts. The examples in the guidance are almost uncomfortably simple:

Fake admin-only credentials: any use signals compromise.
A decoy folder on an executive's desktop: any access is suspicious.
A fake network-scanning tool on a non-technical user's workstation: any execution indicates malicious activity.

Affect: impose cost. Divert adversary effort toward decoy systems and data, seed the environment with decoy accounts, services, and credentials so that reconnaissance produces a misleading picture, or encourage the adversary to exfiltrate large volumes of meaningless data. It does not remove them from the network, but it burns their time and hands it to you.

Elicit: place adversaries in controlled, realistic environments to observe their TTPs and collect CTI. Here the guidance is blunt about the entry price: highly realistic but isolated environments, mature monitoring and logging, and personnel capable of managing the operational and legal risk. The recommendation is explicit: establish basic Expose capabilities first, add selected Affect activities where appropriate, and only then consider Elicit.

Practical translation: if someone pitches you "adversary engagement" before you have one working tripwire and one person who answers the alert, they are selling you stage three of a ten-step process.

The ten-step cycle, unromanticized

Engage defines a process in three phases (Prepare, Operate, Understand), and the guidance walks it through a scenario: a mid-sized high-technology company worried about intellectual property theft, with executives who keep failing phishing simulations.

What that team does, in short:

Prepare (steps 1–6). They document what the adversary does (phishing; discovery of files, shares, and email; credential theft; privilege escalation; lateral movement; exfiltration) and what defenses exist. They define the operational objective: detect intruders who already have an internal foothold, with emphasis on compromised executive accounts and the early stages of lateral movement. They decide how they want the adversary to react (gravitate toward decoys) and what they want the adversary to perceive (high-value credentials for lateral movement and privilege escalation, sensitive technical documents). Then they pick presentation channels: an internal dark net segment of unused IP space routed to a sinkhole, file shares mimicking current R&D projects populated with realistic but non-sensitive documents, and emails to the most phishing-prone executives containing apparent credentials they are told to keep but never use.
Operate (step 7). They deploy during a scheduled maintenance window, test that every decoy actually fires the expected alert, brief leadership on objectives and high-level design, and restrict the detailed decoy map to the people who need it.
Understand (steps 8–10). When something trips, they collect when and how, reconstruct the adversary's sequence of actions, refine detection content and correlation logic, update incident response playbooks, and assess results against success criteria defined before the operation started.

And here are the three step-6 decisions that separate a real program from an experiment:

Document where your decoys are, and keep that documentation outside the production environment, so you are not handing the map to whoever just compromised your network. Write down the expected false positives (IT testing activity, for one) before the on-call analyst discovers them at 3 AM. Coordinate over a secure channel that does not depend on the network you are monitoring.

Three bullets in a twenty-two page PDF, and probably the most valuable thing in it.

Honeytokens: the lowest-friction way in

The guidance devotes a full section to honeytokens (decoy data items or assets with no legitimate purpose, planted among real ones) and compares them against honeypots.

The common types it enumerates: files and documents that appear to hold sensitive information; data records planted alongside real ones; accounts that are disabled or unused, where any authentication attempt is suspicious; credentials (passwords, API keys, tokens), whose use also tells you where the adversary picked them up; email addresses seeded in directories and applications, which reveal unauthorized access to the underlying store; and web artifacts, decoy URLs with no legitimate business use.

The worked example is simple enough to sting. A project manager keeps a personal network share with monthly management briefs for a sensitive project. The security team drops in decoy files named something like Project_Metrics.xlsx and Budget_Data.docx, with realistic but fictitious content, tells the project manager not to open or move them, and instruments access. Because only that person can reach the share, and that person knows, any interaction is a strong indicator of unauthorized activity.

That is the whole control. And it will probably detect sooner than half the rules in your SIEM.

On sourcing, the guidance stays deliberately neutral and lists four paths: open source (good for pilots and thin budgets), commercial (centralized dashboards, reporting, vendor support), homegrown (if you have the engineering capacity), and LOTL, using what you already own, such as EDR, IAM, or DLP, to deploy and monitor tokens without buying anything new. Its evaluation criteria are equally sober: interoperability with existing infrastructure, operational complexity, staffing, and budget.

If you go the platform route, this is what Lokimesh calls breadcrumbs and decoys: inert files, credentials and configuration entries on real systems, leading to decoys that no legitimate user has a reason to touch.

The part almost nobody does: the gap map

The second half of the document is, in practice, a prioritization method. Using a water and wastewater sector scenario, it proposes overlaying three layers on ATT&CK:

Your vulnerabilities, mapped to techniques: phishing (T1566); OT HMIs reachable via Valid Accounts (T1078) and External Remote Services (T1133); command and scripting interpreters (T1059).
Your current defenses, mapped to techniques: strong detection for password spraying (T1110), segmentation mitigating T1190 and T1133, but thin coverage for phishing and PowerShell.
The capabilities of the adversary actually aiming at you, per sector CTI.

The intersection (you are exposed, the adversary uses it, and you have no detection) is exactly where the decoy goes. In the scenario, that overlap yields seven priorities, among them T1078 (an organizational weakness with no detection), T1059 and T1046 (known adversary techniques, no detection), and the entire exfiltration tactic TA0010, which the team decides to cover wholesale because CTI shows the adversary uses multiple techniques to achieve it.

One methodological note that lowers the barrier considerably: if mapping at the technique level is hard, map at the tactic level first and refine over time. Nobody is asking for a perfect heatmap on the first pass.

If you do not emulate it, you do not have it

The closing section is the one most often skipped in practice. After deployment, you emulate: red team, purple team, or threat emulation using the relevant ATT&CK techniques, to verify that decoys trigger as expected and that the alerts surface to a defender who handles them in a timely, appropriate way.

In the scenario, a third-party red team emulates a ransomware campaign against OT configuration documents and cloud backups. Initial access comes from a controlled malicious executable on an IT workstation. During reconnaissance, execution of a seeded network-scanning utility fires the first decoy alert; the decoy remote service and a decoy Active Directory account follow. The team does not just confirm the decoys work. It measures its own incident response and updates placement, detection logic, and procedures accordingly.

The success criteria the document suggests are adoptable as written, today:

Was the decoy alert the primary indication of the intrusion?
If it was not, did it significantly assist the investigation another tool triggered?
Is there a demonstrable reduction in MTTD when the decoy is the detection source, compared to prior incidents or your baseline?

Write down the baseline before you deploy. It is the only way the third question ever gets an answer.

Checklist: the next 90 days

Days 1–30: Floor.

Pick three critical assets and three critical people. Nothing more.
Seed one honeytoken of each type: a file, a disabled account, a credential.
Instrument the alert in the SIEM/EDR you already own, and trip it yourself.
Document locations and expected false positives outside production.
Record your current MTTD.

Days 31–60: Coverage.

Build the ATT&CK heatmap with all three layers (vulnerability / defense / adversary).
Prioritize the no-detection overlap and map each technique to an Engage activity.
Add diversity: multiple token types across multiple locations (servers, workstations, cloud repositories, identity systems).
Write the investigation procedure for each alert type.

Days 61–90: Proof.

Run threat emulation with techniques your sector actually faces.
Measure: did it fire, did it surface, did anyone act, and how fast?
Tune thresholds to cut benign triggers without losing sensitivity.
Hold a structured review of successes, failures, and residual gaps. Plan the next iteration.

What the guidance does not say, and is worth keeping in mind

A decoy with no alert owner is decoration. The document assumes somebody triages and escalates. If you do not have that somebody, that is your project, not deception.
Telling the legitimate user is part of the control. In both worked examples, the project manager's share and the credentials mailed to executives, the human knows and cooperates. A decoy your own staff walks into daily is a false-positive factory.
A decoy's realism is its attack surface. The guidance does not cover how to keep a capable adversary from fingerprinting the decoy, but the "distinct from normal behavior" criterion cuts both ways: what looks anomalous for your user can look anomalous to whoever is watching from inside.
CISA does not endorse products. The disclaimer is explicit: the guidance does not recommend or favor any commercial entity, product, or service, and every action it describes is voluntary. If any vendor shows you this document as an endorsement, they are misreading the last page.

For a broader primer on where decoys fit in a security program, see our practical guide to modern cyber deception.