Honeytokens vs Honeypots: Which Deception Control to Deploy First

Security teams that want deception often buy or build a honeypot first, when a handful of canary credentials would have caught the same intruder earlier, for less money and with less upkeep. Honeytokens and honeypots both rely on the same idea: a thing with no legitimate use, so any touch is a signal. They differ in what they are, where in an intrusion they fire, what they cost to run and how well they fit cloud and non-human identity estates. This guide compares the two for detection engineers, SOC leads and security architects deciding where to spend a deception budget. It does not repeat the build manuals: the Honeytokens and Canary Credentials Guide and the Honeypot deployment guide cover implementation in depth.

Key takeaways

• The short answer: start with honeytokens for credential theft and cloud abuse, add internal honeypots when network reconnaissance and lateral movement are your blind spot.
• They fire at different points: a honeytoken fires when stolen data is used, a honeypot fires when an intruder scans or connects to a decoy host or service.
• Upkeep differs by an order of magnitude: a canary credential is a record in a register and a log query; a honeypot is a host you must patch, contain, monitor and keep plausible.
• False positives come from your own tools: secret scanners, vulnerability scanners, backup jobs and curious staff trip decoys far more often than attackers do, so exclusions and a decoy register matter more than the product.
• Cloud and NHI estates favour tokens: there is often no flat network to scan, but there are always access keys, service principal secrets and tokens in files and pipelines to steal.

Definitions and the core difference

A honeypot is a decoy system or service. It listens on the network, looks like something worth attacking (an SSH server, a file share, a database, an industrial controller) and records whoever connects. A honeytoken is a decoy piece of data: a credential, an API key, a document, a database row or a DNS name, planted where a real one would sit. It does nothing until someone reads it and then uses it somewhere you can observe.

MITRE D3FEND files both under its Deceive tactic but as different techniques. Honeypots map to Decoy Network Resource (D3-DNR), which D3FEND defines as deploying a network resource to deceive an adversary, and to the honeynet family: Standalone Honeynet (D3-SHN), Integrated Honeynet (D3-IHN) and Connected Honeynet (D3-CHN). Honeytokens map to Decoy User Credential (D3-DUC), Decoy Session Token (D3-DST) and Decoy File (D3-DF). NIST SP 800-53 Rev. 5 covers both under control SC-26 Decoys.

Detection points in the kill chain

The most useful way to choose is to ask which attacker behaviour you cannot currently see, then place the decoy on that step. The table maps common steps to ATT&CK techniques and to the decoy that sees them.

Two patterns follow. First, honeytokens catch the attacker who reads and reuses, which is how most cloud and pipeline intrusions progress: secrets are lifted from a laptop, a repository or a CI runner and replayed from the internet. Second, honeypots catch the attacker who explores, which is how most on-premises ransomware and hands-on-keyboard intrusions progress: discovery scans, then attempts against SMB, RDP and SSH. A honeytoken can fire from anywhere in the world, long after the theft; a honeypot only fires if the intruder reaches the segment it sits in.

Threat model and architecture: honeytokens

Threat model: an adversary or malware has read access somewhere secrets accumulate and will try what it finds. Infostealers, a compromised build dependency, a leaked repository or an insider all produce this condition. The canary assumes the theft has already happened and aims to make the first use loud.

Architecture in words: issue a genuine credential from the real provider, attach no permissions, place it beside real secrets, and route the provider's audit events for that identity to an alert. For AWS this is an IAM user with no policies, watched through CloudTrail; for Entra ID it is an app registration with no role assignments, watched through service principal sign-in logs, which Microsoft lists as one of four sign-in log types alongside interactive, non-interactive and managed identity sign-ins. For Active Directory, Microsoft Defender for Identity supports a Honeytoken tag on users and devices, and its documentation states that any sign-in from a honeytoken account triggers an alert. Hosted callback services work the same way: the Canarytokens AWS keys token alerts whenever the keys are used via the AWS API, and its documentation warns that Amazon's logging pipeline can add a delay of between 2 and 30 minutes.

Failure modes: the canary has permissions after a policy change; it is placed where no attacker looks; the alert routes to a mailbox nobody reads; secret scanners or rotation jobs touch it and the team learns to ignore it; or an attacker checks the key first. On the last point, the AWS STS GetAccessKeyInfo operation returns the account ID that owns a key, so a canary key issued from an obviously separate "canary" account can be recognised. Issue canaries from accounts whose IDs and names look like your production estate.

Controls: a decoy register (identity, location, owner, date), explicit deny policies, a scheduled test that trips each canary, and suppression rules keyed on known scanner identities. The Honeytokens and Canary Credentials Guide covers placement and design for each provider.

Threat model and architecture: honeypots

Threat model: an adversary is inside a network segment and is mapping it, probing services or guessing passwords. The decoy assumes the attacker will touch something they do not recognise.

Architecture in words: a low-interaction honeypot is a small host or container that emulates services and logs every connection. OpenCanary, for example, documents login-based modules for SSH, FTP, HTTP, HTTPS, MSSQL, MySQL, Telnet and VNC, plus others for Git, Redis, SNMP, SIP and TFTP, with alert handlers for syslog, JSON over TCP, email, webhooks and chat tools. A medium-interaction honeypot such as Cowrie emulates a UNIX shell with a fake filesystem, records sessions for replay and writes JSON audit logs; its proxy mode places it in front of a real system for higher interaction. Internal detection needs low interaction; research into attacker behaviour needs more. (Projects are listed alphabetically and are examples, not recommendations.)

Failure modes: the decoy sits in a segment attackers never scan; it looks fake (default banners, a hostname nobody uses); outbound traffic is not blocked, so a compromised high-interaction decoy becomes a launch point; it is not patched; or its logs never reach the SIEM. The Securing the deception platform itself page covers hardening the decoy estate.

Controls: deny-by-default egress except logging, separate management, no real data, change control on placement, a triage playbook and a monthly alert path test. The Honeypot deployment guide covers placement and containment step by step.

Cost and upkeep

Licence prices vary too much to quote, but the work does not. The table compares the recurring effort for a mid-sized estate.

Commercial deception platforms reduce the honeypot burden by generating decoys and rotating their content, but the platform itself becomes a privileged system that needs securing. The Deception Technology Buyer's Guide covers how to evaluate one.

False positives and alert fidelity

Both controls are sold on near-zero false positives, and both deliver it only after tuning. The noise comes from inside:

• Secret scanners: repository and pipeline scanners find canary keys and some validate them against the provider, which trips the canary. Register canaries with the scanning team and suppress validation calls from known scanner identities, without suppressing the canary itself.
• Vulnerability and asset scanners: authenticated and unauthenticated scans will connect to every honeypot. Exclude the scanner source addresses and schedule, and alert on scanner traffic outside the window.
• Backup, migration and indexing jobs: these copy and read files containing canary documents or credentials. A read is not a use; alert on use.
• Staff curiosity and red teams: a well-named decoy will be tried by an administrator. Treat it as a real alert the first time and decide afterwards; red team activity should be deconflicted, not suppressed.
• Automated attacker validation: mass key-checking tools try harvested keys within minutes. That is a true positive: the location is compromised.

The rule that keeps both controls trustworthy is the same: an alert is an incident until proven otherwise, and every proven benign trigger produces a named exclusion with an owner, never a blanket mute.

Cloud and NHI fit

Cloud estates change the calculation. There is often no flat internal network for an attacker to scan, security groups block most east-west traffic, and the path to impact runs through identities: access keys, service account keys, OAuth tokens, workload credentials and pipeline secrets. That is why honeytokens usually come first in cloud and non-human identity programmes.

• Cloud access keys: canary keys in developer credential files, CI variables, AMIs and container images catch T1552.001 and T1078.004 directly, wherever the attacker replays them.
• Instance metadata: an attacker abusing T1552.005 Cloud Instance Metadata API gets a real role credential, not a canary; detection here comes from role usage analytics, not decoys. Do not assume canaries cover it.
• Service principals and app registrations: a decoy app registration with a secret and no permissions is cheap to create and monitored through sign-in logs.
• Kubernetes: a service account token with no RoleBindings, left in a Secret or kubeconfig, is watched in the API server audit log. See the Kubernetes Service Account Token Guide.
• AI agents: canaries in agent memory, tool configuration and retrieval stores can reveal prompt injection that leads an agent to exfiltrate secrets. The AI Agent Honeytokens and Canaries guide covers this.
• Cloud honeypots: still useful in a VPC with many reachable workloads, or as a decoy database or storage endpoint, but each VPC or account needs its own decoy, which raises the cost.

Honeytoken alerts are, in practice, identity threat detection for machine credentials. Feed them into the same pipeline as other identity alerts; the ITDR Guide explains how.

When to use each: decision guidance

Small versus large organisations: a small organisation can run ten well-placed honeytokens with almost no cost and should not run a honeypot it cannot patch or watch. A large organisation needs both, because its estate contains both credential-heavy cloud workloads and legacy networks, and it can afford the upkeep. The trade-off is coverage breadth (tokens scale cheaply) against path visibility (honeypots show where the intruder is on the network).

Worked scenarios

Scenario 1, SaaS company on AWS and GitHub: the team plants a canary access key in each developer's credential file template, in two CI variable groups and in one base container image. Three weeks later the canary from a contractor's laptop is used from a hosting provider address. Because the key had no permissions, nothing was accessed; because it sat beside real keys, the team revokes every credential on that laptop and in its synced folders, finds an infostealer, and the alert has given them the theft location. A honeypot would have seen nothing: the attacker never touched the network.

Scenario 2, manufacturer with a flat Windows estate: the team places low-interaction decoys offering SMB and RDP in the server and engineering segments and tags two dormant directory accounts as honeytokens. An intruder using a stolen VPN account runs a discovery scan; the honeypot in the server segment logs the scan within minutes and identifies the source host. The honeytoken accounts would only have fired had the attacker tried them. Here the honeypot gave the earlier signal.

Scenario 3, combined: a decoy service account appears in a script on a file share. When it is used against the honeypot's SMB service, the SOC sees both the credential theft and the lateral movement attempt, from one source, in one correlated alert. This is the strongest pattern for mature teams.

Rollout approach

1. Pick the blind spot: name the ATT&CK steps you cannot see today using the kill chain table above.
2. Pilot honeytokens first: five to ten canaries in the highest-value secret locations, a decoy register, and one alert route to the on-call analyst.
3. Test before trusting: trip each canary yourself and measure time to alert; register scanner identities and add named exclusions.
4. Add honeypots where scanning is the risk: one low-interaction decoy per high-value segment, egress denied, logs in the SIEM, triage playbook written.
5. Expand by template: bake canaries into image builds and pipeline templates; add decoys only when a new segment justifies one.
6. Roll back cleanly: to retire a canary, delete the identity and its register entry together; to retire a honeypot, remove DNS records and firewall rules before the host, so no stale address remains reachable.

Detection and measurement

Log provider audit events for every canary identity, honeypot connection and authentication logs, and the scheduled test results. Track:

• Time to alert: from a test trip to the analyst seeing it, for each decoy type.
• Test pass rate: share of decoys that alerted correctly in the last scheduled test.
• Coverage: share of secret stores, pipelines and image templates with a canary; share of high-value segments with a decoy.
• Benign trigger rate: benign trips per month, with the share closed by a named exclusion.
• Register accuracy: canaries and decoys found in logs or scans that are missing from the register (target zero).

Common failure patterns

• Buying a honeypot for a cloud problem: decoy hosts in a VPC that attackers never scan, while keys in pipelines go unwatched.
• Canaries with real permissions: an inherited group or a broad managed policy turns the decoy into a working credential.
• Treating a canary trip as a contained event: revoking only the canary, when every real secret stored beside it is compromised.
• Unmonitored or unpatched honeypots: a decoy left running for a year becomes a vulnerable host on the network.
• Muting scanners wholesale: suppressing all alerts from a scanner range hides an attacker who lands on that host.
• Obvious decoys: canary accounts in a separate, clearly named cloud account, or honeypots with default banners and hostnames.

Framework mapping

Decision checklist

• Have you named the intrusion steps you cannot see today, and mapped each to a decoy type?
• Is every canary credential issued by the real provider, with zero permissions and an explicit deny?
• Do canary accounts and identities look like production, including account IDs and naming?
• Is there a decoy register shared with secret scanning, vulnerability management and red team owners?
• Does every honeypot deny outbound traffic except logging, and is it patched like a server?
• Is a canary trip treated as compromise of everything stored beside it?
• Is every decoy tested on a schedule, with time to alert recorded?
• Do you have the staff to watch a honeypot before you build one?

Practitioner checklist

• Plant canary credentials in developer credential files, CI variables, base images and the secrets manager first.
• Issue cloud canaries from accounts that resemble production, never a clearly labelled decoy account.
• Tag dormant directory honeytoken accounts in your identity threat detection tool.
• Place low-interaction honeypots only in segments an intruder will scan, with egress denied.
• Route every decoy alert to a named, staffed queue at high priority.
• Keep a decoy register and update it in the same change as the decoy.
• Trip each decoy on a schedule and record time to alert.
• Replace blanket scanner suppression with named, owned exclusions.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls (SC-26 Decoys)
• MITRE D3FEND: Decoy Network Resource (D3-DNR)
• Cowrie: Project documentation
• Microsoft Learn: Defender for Identity entity tags (Honeytoken)
• Microsoft Learn: Sign-in logs in Microsoft Entra ID
• AWS: STS GetAccessKeyInfo API reference
• Canarytokens: AWS keys token documentation
• OpenCanary: Configuration documentation

Related NHI Mgmt Group resources: Deception Technology Guide, Deception Technology Deployment Guide, Git Secret Scanning Guide, Detection Engineering Guide.