Deception technology places fake systems, accounts or data where only an intruder would look, so any touch is a high-confidence alert. It does not stop attacks, it detects and studies them. NIST lists decoys as a control, and MITRE publishes a framework for adversary engagement. It works best as a complement to logging.
What does the standards body say?
NIST SP 800-53 includes a control named Decoys, SC-26. Its statement asks organizations to include components within systems that are specifically designed to be the target of malicious attacks, for detecting, deflecting and analyzing such attacks. Those three verbs describe the full range of what deception can do.
MITRE maintains Engage, a framework and website about adversary engagement and cyber deception. Its public repository invites people to talk about cyber deception, which tells you it is treated as a discipline with its own vocabulary and not a product category.
What forms does it take?
Honeypots are fake servers or services that look real but hold nothing valuable. They sit on the network and wait. A real user has no reason to connect to them, so a connection is suspicious.
Honeytokens are fake credentials, API keys, database rows or documents. An access key that is never used by any application is planted in a repository or a config file. If it is ever used, someone found it where they should not have been.
Decoy accounts look like privileged accounts but have no real access. An attempted sign-in is an alert by definition.
Canary files and links sit in shared storage. Opening them triggers a notice.
Why can it be high signal?
Most detection drowns in noise. Normal users trip alerts constantly. A decoy has no legitimate use, so even one event deserves attention. This makes it useful for small teams that cannot review thousands of alerts a day.
What are the limits?
Decoys detect, they do not prevent. An attacker who never touches the decoy never trips it. They also need upkeep: a fake server with an outdated look can be spotted, and a honeytoken must be placed where a real attacker would plausibly find it.
Safety is the other concern. A honeypot is a system an attacker can interact with. If it is poorly isolated, it becomes a foothold. Keep decoys in isolated segments, with no credentials or paths that lead to real assets, and make sure alerts reach a person.
There are legal and operational questions as well. Review with legal counsel before deploying anything that records attacker activity, and tell your incident team that decoys exist so they do not mistake their own test for an attack.
A constructed example
A software team stores deployment keys in a secrets manager and, for a trap, creates one extra cloud access key with no permissions beyond one logging call. They commit that key to a private internal repository, in a file named like an old backup. Their alert rule says any use of that key pages the on-call engineer. Six months later, an engineer's laptop is compromised through a malicious browser extension, and the malware scans local repositories for keys. The decoy key is used from an unfamiliar address within minutes. The alert fires before any real key is used, and the team rotates real secrets while the attacker's scan is still running.
How to check or apply this
- Pick one asset type to start. Honeytokens in code and config are cheap.
- Make each decoy unique, so an alert tells you exactly where it was found.
- Ensure decoys grant no useful permissions and cannot reach real data.
- Route alerts to a person, with a documented response.
- Tell your incident responders what exists, and keep a register of decoys.
- Rotate and refresh them, and test that alerts still fire.
- Treat deception as a layer on top of logging, patching and least privilege.
Quick check
Does deception technology replace monitoring?
No. It adds a few very reliable signals. You still need normal logging and review.
Is a honeytoken the same as a real secret?
No. It looks real, but has no useful permissions. Its only job is to alert when used.
Sources
Last reviewed: 18 October 2026.
