On September 16, CISA published new guidance for using cyber decoys to detect attackers who rely on valid credentials, native administration tools, and living-off-the-land techniques. The guidance is aimed in part at small and midsize organizations that need practical detection improvements without a major architecture change.
The simplest version sounds attractive: place a fake file, credential, account, or service where an intruder might find it, then alert when someone touches it. Because the decoy has no legitimate business use, the interaction should be suspicious by definition.
Deployment is the easy part. The control only works if the alert reaches someone, carries enough context to investigate, and leads to a response that has already been considered. An unmonitored honeytoken is an undocumented artifact. A poorly isolated honeypot can become another system an attacker controls.
CISA's cyber decoy guidance provides a useful planning framework. Security teams still need to turn that framework into an operating process.
What CISA means by a cyber decoy
The guidance uses several related terms that describe different parts of a deception operation.
A honeytoken is a fake data element or logical object, such as a record, file, secret, or credential, that has no valid business purpose. A breadcrumb is an artifact that directs an intruder toward a decoy. A tripwire is the monitored condition that produces an alert. A honeypot is a realistic system or service intended to attract and observe adversary activity while keeping it away from production assets.
CISA organizes decoy objectives around three goals drawn from MITRE Engage: expose, affect, and elicit. Expose focuses on detecting the adversary. Affect attempts to increase the attacker's cost or disrupt the operation. Elicit draws the attacker into a controlled environment so defenders can observe behavior and collect intelligence.
Most smaller teams should begin with expose. A fake file that generates a high-confidence event when opened is much easier to govern than an interactive honeypot designed to sustain attacker engagement. The latter needs stronger isolation, logging, maintenance, legal review, and staff who can safely interpret what happens inside it.
The first objective does not need to be ambitious. It needs to be unambiguous.
Start with behavior that should never occur
A useful decoy is built around an action with no legitimate explanation. If normal users, backup tools, indexers, vulnerability scanners, or administrators will routinely touch the asset, the resulting alerts will lose value.
Candidate actions might include:
- Authentication to a decoy administrative account that has no production privileges
- Access to a fake sensitive document placed in a monitored location
- Use of a decoy secret embedded in a file that ordinary applications do not read
- Connection to an unused management service placed on a controlled network segment
The team should be able to describe the detection in one sentence: "This alert means an identity or process accessed an object that no approved workflow uses."
That sentence needs validation. Before deployment, ask system owners whether discovery tools, endpoint security products, data classification platforms, backup jobs, search services, or administrative scripts could activate the decoy. Run the same checks in a test environment. If legitimate automation triggers the event, change the placement or the design rather than building a large allowlist around a weak signal.
Realism also has limits. A decoy credential must not provide access to production data or meaningful privilege. A fake document should contain no sensitive information. A decoy service should not expose a route into trusted systems. The objective is to observe unauthorized behavior, not create an attractive new path to business assets.
Treat the alert as incident intake
A decoy interaction deserves a defined intake path because it may be the first visible sign of post-compromise discovery or lateral movement. Routing it into a general mailbox or a low-priority queue defeats the purpose.
Every deployed decoy should have an owner, a severity, an escalation route, and a response procedure. The alert should identify the decoy, where it was placed, the interaction that occurred, and the system expected to collect the supporting evidence.
For an endpoint-based tripwire, useful context can include the source host, logged-on user, process tree, command line, file access event, network destination, and nearby authentication activity. An identity decoy may require sign-in details, source address, session information, device context, and evidence from the systems the account attempted to reach.
The initial triage should answer several practical questions:
- Was this an authorized test, maintenance task, or known automated process?
- Which user, endpoint, workload, or external source generated the interaction?
- What happened immediately before and after the alert?
- Does the same identity or host show unusual authentication, process, or network activity elsewhere?
- Is containment required before the investigation continues?
The playbook should also define evidence preservation. Endpoint events, identity logs, network records, process data, and cloud audit logs may have different retention periods. Waiting for a meeting the next morning can remove the detail needed to distinguish a test from a compromised account.
Automation can enrich and route a decoy event, but destructive actions need care. Automatically isolating an endpoint or disabling an account may be appropriate for a well-tested, high-confidence detection. It can also interrupt business if the decoy was activated by a new scanner or an undocumented process. Test the response logic under controlled conditions before granting it authority to contain systems.
Isolate the decoy from production
NIST SP 800-53 control SC-26 describes decoys as components intended to detect, deflect, and analyze attacks. Its discussion also calls for isolation measures so malicious code directed at a decoy cannot spread into organizational systems.
Isolation becomes more important as the decoy becomes more interactive. A honeytoken that calls a monitored endpoint has a smaller operating surface than a realistic server that accepts connections and lets an attacker run commands.
For a honeypot or decoy service, the design should restrict outbound communication, remove production credentials, limit trust relationships, and separate administration from ordinary user access. Logging should leave the decoy environment so an attacker cannot erase the only record of the session. The team should also decide whether the system will be patched like production, deliberately present selected weaknesses, or only emulate services. That decision affects both risk and realism.
CISA also recommends keeping sensitive decoy documentation outside the production environment. An intruder who finds a current inventory of every fake account and system can avoid the traps. The inventory still needs to exist. It should record placement, owner, alert path, expected telemetry, test schedule, dependencies, and retirement date.
A forgotten decoy is a control failure waiting to happen. Accounts may be repurposed, file shares may change owners, logging pipelines may be replaced, and firewall rules may drift. The decoy must be maintained through the same change process used for other detection controls.
Test the full detection chain
Creating the artifact does not prove the control works. An authorized test should reproduce the expected interaction and follow the event through collection, correlation, notification, triage, evidence gathering, escalation, and closure.
MITRE's adversary engagement handbook treats deception as an iterative, goal-driven process rather than a technology that can be deployed and forgotten. That distinction matters. The useful test is not whether the fake file exists. It is whether the organization can detect and handle access to it.
A practical validation should confirm:
- The event appears in the expected telemetry source
- The detection rule fires with the intended severity
- The alert reaches the monitored queue and assigned owner
- The analyst can identify the source identity and system
- The response procedure points to available evidence
- Containment actions work as intended and do not exceed their scope
Record the result and schedule another test after material changes to endpoint agents, identity systems, file platforms, SIEM rules, network segmentation, or on-call routing.
Silence between tests is not proof that the decoy is healthy. A control designed around zero legitimate use may remain quiet for months. Health checks must verify the collection and alert path without training ordinary users to interact with the artifact.
Know when to wait
Decoys should not displace basic controls. If privileged accounts lack phishing-resistant MFA, critical systems remain unpatched, endpoint telemetry is incomplete, or high-severity alerts routinely wait for review, another detection source may add complexity without improving response.
The SANS NewsBites discussion of CISA's guidance raised the same operating concern. Several contributors supported decoys as high-confidence detection tools while cautioning that teams need the capacity to monitor and act on the signal. A quiet, high-value control can also be forgotten because it produces fewer events than noisy tools.
That does not require abandoning the idea. It argues for a smaller pilot. One carefully placed honeytoken with tested routing is more useful than a broad deception environment that no one owns.
Build one controlled pilot
Choose a use case tied to a credible attack path, not a random place where a fake file is easy to create. Credential theft, internal reconnaissance, access to executive data, and discovery of administrative infrastructure are reasonable starting points when they match the organization's threat model.
For the pilot:
- Define the suspicious behavior and why legitimate activity should never trigger it.
- Select a low-complexity decoy and place it near the behavior you want to detect.
- Confirm isolation and remove any path to production privilege or sensitive data.
- Route the event into an actively monitored security workflow.
- Write the triage, evidence, containment, and escalation steps before activation.
- Run an authorized test and retain the result as control evidence.
- Review the pilot after 30 to 60 days, then expand, redesign, or retire it.
The review should consider more than alert count. Check whether ownership stayed current, telemetry remained available, the detection survived environment changes, and responders could still explain what the alert means.
CISA's guidance makes cyber decoys more approachable for teams that do not operate a dedicated deception program. The operational standard should remain strict. Every honeytoken needs a clear reason to exist, a monitored signal, a safe design, and a tested response.
