What are honey tokens and how do you use them to catch intruders?

A honey token is a fake secret, record or credential placed where an intruder might find it and where no legitimate user or system would ever use it. Because real activity never touches it, any use is a high confidence alert that something is looking where it should not.

How are honey tokens related to honeypots?

NIST's glossary defines a honeypot as a system, or a system resource such as a file on a server, designed to be attractive to potential intruders. A honey token is the small, resource sized version: a single credential, key, document or database row.

MITRE D3FEND places the idea under Decoy Object, defined as an object created and deployed to deceive attackers. Its overview adds the key operating principle: decoy objects have no legitimate business purpose, so any communication with them should be logged and analysed for indicators of compromise. D3FEND lists subtechniques including decoy files and decoy user credentials.

What kinds of honey token are there?

• Decoy cloud keys. An access key that looks real, in a configuration file or repository, with no permissions. Any attempt to use it triggers an alert.
• Decoy accounts. A user account named like an administrator, with a strong password nobody uses. Any login attempt is suspicious.
• Decoy database rows. A customer record with a unique email address that is monitored. If it receives mail, someone exported the table.
• Decoy documents. A file named like a sensitive spreadsheet that calls a monitored address when opened.
• Decoy DNS names or URLs. An internal address that no real system queries.

Why do they work?

Most detection looks for bad behaviour in a sea of normal behaviour, and it is noisy. A honey token inverts the problem. There is no normal use, so there is almost no noise. That makes them cheap to run and easy to explain to a response team: if this fires, treat it as real.

They are also useful at the stage after an intruder has gotten in. Attackers searching a machine for credentials, a technique MITRE ATT&CK describes under credential access, often use whatever they find. A decoy turns that search against them.

A constructed example

A company stores deployment notes in a shared repository. A security engineer adds a file named old-backup-credentials.txt containing a fake cloud access key with no rights, registered with an alerting service the company controls. Eight months later an engineer's laptop is compromised by malware. The attacker copies files from the repository and tries the key against the cloud provider. The alert fires within minutes, naming the file path where the key was stored. The response team knows which machine to isolate, because only that machine's user had the repository checked out.

Without the token, the attempt would have been one failed login among thousands.

What are the limits?

• They only detect, not prevent. A token tells you someone is in, not how.
• They need placement. A decoy in a place nobody searches will never fire.
• They can be recognised. A skilled intruder may spot odd names or unreal metadata. Make decoys blend in.
• They can raise false alarms. Backup tools, scanners and curious staff may touch decoys. Keep decoys out of paths that automation walks.
• They need a response. An alert nobody reads is only decoration.

How to check or apply this

1. Choose three places where intruders look: a code repository, a file share and a cloud configuration.
2. Create a decoy in each, with realistic names and no real permissions.
3. Route alerts to the on-call channel with a clear note: "No legitimate use exists, treat as an incident."
4. Write down where each token lives, so you do not forget one or mistake it for a leak later.
5. Exclude decoys from scanners and backup jobs, or tag them so the tools expect them.
6. Test one alert each quarter, and rotate tokens when a laptop or repository changes hands.
7. Never place a token that could harm real users or touch production data.

Decoys complement, not replace, secret scanning. Remove real leaked keys from code and rotate them. A fake one is a tripwire, not a policy.

Quick check

Sources

• NIST CSRC Glossary, honeypot
• MITRE D3FEND, Decoy Object (D3-DO)
• OWASP Secrets Management Cheat Sheet

Last reviewed: 18 October 2026.