Deception Technology Deployment Guide

Deception fails quietly: decoys get deployed in the wrong places, alerts land in a queue nobody owns, and a year later the honeytokens have been tripped by a backup job so often that real hits are ignored. The technology is simple; the deployment is where the value is won or lost. This guide is a deployment playbook for security operations and detection engineering teams: how to set objectives, map placements to the attack paths you care about, build the alert pipeline, test without polluting your data, and keep decoys believable over time. It assumes you know what honeypots, honeytokens and decoy credentials are. If not, start with the Deception Technology Guide, and use the Deception Technology Buyer's Guide if you are still choosing a platform.

Key takeaways

Deploy against named attack paths. Each decoy should exist because a specific technique, such as Kerberoasting or credentials-in-files, would touch it on the way to something valuable.
Keep a decoy register. Every decoy needs an owner, a location, an expected-touch list and a review date, or it decays into noise or a liability.
Route alerts as high severity from day one. A decoy interaction has no legitimate reason, so it deserves an immediate triage path, not a weekly report.
Exclude your own tools explicitly. Vulnerability scanners, backup agents, search indexers and identity hygiene tools will touch decoys; whitelist them by identity, not by IP range alone.
Measure coverage and dwell, not decoy count. Attack-path coverage, time from touch to triage and tested-alert rate show whether deception works.

Set objectives before placing anything

MITRE Engage, the adversary engagement framework from MITRE, organises engagement around three strategic goals: Expose (collect and detect), Affect (prevent, direct and disrupt) and Elicit (reassure and motivate an adversary so you learn more). Most enterprise programmes should start and stay in Expose: decoys as high-fidelity tripwires. Affect and Elicit operations need legal review, dedicated staff and isolated infrastructure, and they belong to mature teams with a threat intelligence function.

Objective	Typical decoys	Team needed	Fits
Early warning of lateral movement (Expose)	Honey credentials, decoy hosts, decoy shares	SOC with on-call triage	Most organisations
Detect credential theft from endpoints and code (Expose)	Canary API keys, cloud access keys, tokens in files and repositories	SOC plus platform engineering	Cloud-heavy and software organisations
Detect data staging (Expose)	Canary documents, decoy database rows	SOC plus data owners	Regulated data holders
Slow or redirect intruders (Affect)	Decoy subnets, fake services that consume attacker time	Detection engineering and network team	Mature SOCs
Gather adversary intelligence (Elicit)	High-interaction environments, personas	Dedicated engagement team, legal oversight	Large enterprises, government, research

Write the objective, the attack paths in scope, the owner of the alerts and the success measures on one page. That page is what you review every quarter.

Map placements to attack paths

Placement is the core skill. Walk the routes an intruder takes from initial foothold to your crown jewels, and put a decoy where each technique naturally reaches. ATT&CK gives the technique, D3FEND gives the matching decoy countermeasure.

Attack technique (ATT&CK)	Decoy placement	D3FEND technique
T1558.003 Kerberoasting	Decoy service account with a service principal name, a long random password and no real service	D3-DUC Decoy User Credential
T1087.002 Domain Account discovery	Attractive-looking admin accounts that are disabled for logon at the application level but visible in the directory	D3-DUC Decoy User Credential
T1003 OS Credential Dumping	Fake cached or in-memory credentials seeded on endpoints and jump hosts	D3-DUC Decoy User Credential
T1552.001 Credentials In Files	Scripts, config files and password spreadsheets on shares containing canary credentials	D3-DF Decoy File
T1135 Network Share Discovery and T1083 File and Directory Discovery	Decoy shares and folders with names that match your naming scheme (Finance, HR-Payroll)	D3-DF Decoy File, D3-DNR Decoy Network Resource
T1046 Network Service Discovery and T1018 Remote System Discovery	Decoy hosts and services in each server VLAN, matching local operating systems	D3-DNR Decoy Network Resource, D3-IHN Integrated Honeynet
T1021.002 SMB/Windows Admin Shares	Decoy servers that accept connection attempts and log them	D3-DNR Decoy Network Resource
T1552.005 Cloud Instance Metadata API and cloud key theft	Canary cloud access keys with no permissions, placed in instance user data, CI variables and developer laptops	D3-DUC Decoy User Credential, D3-DO Decoy Object
Session hijacking with stolen tokens	Decoy session tokens and cookies on high-value endpoints	D3-DST Decoy Session Token

The Uber breach of 2022 is a placement lesson: after the initial foothold, the intruder found privileged credentials in a script on a network share. A canary credential in exactly that kind of script, on exactly that kind of share, is where deception earns its keep. Detailed guidance on credential canaries is in the Honeytokens and Canary Credentials Guide.

Density and believability

Density: our starting point is at least one decoy host per server subnet, one honey account per tier of your admin model, and canary credentials on every jump host and in each CI system. Increase where attack paths converge.
Naming: copy your real conventions. A decoy called honeypot01 in a network of LON-SQL-07 style names is useless.
Age and activity: accounts with a creation date of last week and no logon history stand out. Where your platform supports it, give decoy accounts plausible attributes, group memberships and a realistic password last-set date.
Diversity: MITRE Engage lists artifact diversity as an activity; vary file types, formats and locations so one discovered decoy does not reveal the pattern.

Choose the decoy types for each environment

Environment	Decoys that work	Telemetry that fires the alert
Active Directory	Honey user and service accounts, decoy SPNs, decoy computer objects	Domain controller authentication events (Kerberos service ticket requests and logons for the decoy), identity threat detection alerts
Endpoints and jump hosts	Seeded credentials, decoy RDP and SSH entries, canary documents	EDR telemetry, authentication attempts with the seeded credential
File shares and collaboration	Canary documents that call home when opened, decoy folders	File access auditing, document beacon callbacks
Cloud (IaaS)	Access keys with no permissions, decoy storage buckets, decoy secrets in the secrets manager	Cloud audit log entries for any API call by the decoy key, including denied calls
Source code and CI/CD	Canary tokens in repositories, pipeline variables and container images	Provider audit log for key use; secret scanning alerts
Network	Low-interaction decoy hosts and services per segment	Connection logs from the decoy, network detection
Data stores	Decoy rows and seed records (fake customers, email addresses you monitor)	Database audit, mail received at seeded addresses, external monitoring

Some identity platforms provide native honeytoken features. For example, Microsoft documents a honeytoken entity tag in Defender for Identity: an account tagged as a honeytoken raises an alert on any sign-in. Native features are the fastest way to start in that environment; confirm the current behaviour in the platform documentation. For low-interaction host decoys, see the honeypot deployment guide.

Build the alert pipeline

A decoy without a response path is a liability: it tells you someone is inside and nobody acts. Build the pipeline before the first decoy goes live.

Collect: make sure the telemetry in the table above is already flowing into the SIEM. For cloud keys, confirm denied API calls are captured in the audit trail; for directory decoys, confirm the right domain controller audit policies are on.
Enrich: join each alert to the decoy register automatically, so the analyst sees decoy type, placement, owner and the attack path it represents.
Prioritise: set decoy alerts to high severity. A touch from an unknown identity or host should page on-call.
Triage questions: which identity and source host touched the decoy, what else did that identity do in the last 24 hours, is the source on the exclusion list, and was the decoy itself found in a place it should not be (copied, exfiltrated).
Respond: isolate the source host, reset or disable the identity used, and start a hunt from the source. Use the Identity Threat Hunting Guide for credential-based paths.
Close the loop: every true positive and every false positive updates the register: tune, move or retire the decoy.

Write the detection logic in your detection-as-code repository so it is versioned and tested like any other rule. The Detection Engineering Guide covers the workflow.

The decoy register

Treat decoys as assets. The register is a controlled list, stored with restricted access because it is a map of your traps.

Identifier and type: decoy account, file, host, key or token.
Location: exact host, share path, repository, OU or cloud account.
Attack path and technique: the ATT&CK ID it covers.
Expected touches: the named tools and service identities allowed to see or touch it (backup, scanner, DLP, indexer).
Owner and review date: who maintains it and when it was last checked for believability and alerting.
Last test: date and result of the most recent synthetic trigger.

Keep the register out of general-purpose wikis and ticket systems. If an intruder reads it, every decoy is burned.

Rollout, testing and rollback

Week 1 to 2, preparation: agree the objective page, confirm telemetry, build the alert rule and runbook, and brief the SOC.
Week 3 to 4, quiet pilot: deploy a small set (for example five honey accounts, ten canary files and two decoy hosts) in one site or business unit. Run them in alert-to-test-queue mode for two weeks to discover which tools touch them.
Week 5, exclusions: add legitimate touchers to the exclusion list by service identity and host. Prefer fixing the tool configuration (exclude decoy paths from indexing) over blanket suppression.
Week 6, go live: switch pilot decoys to high-severity production alerts, then trigger each one synthetically to confirm end-to-end paging.
Months 2 to 4, expand: add environments in order of attack-path value: directory and jump hosts first, then cloud keys and CI, then data stores.
Ongoing: test each decoy at least quarterly (our recommendation), and refresh believability attributes twice a year.

Rollback: because decoys are additive, rollback is removal. Keep a script or runbook per decoy type that deletes the object and its alert rule cleanly, and update the register. Never leave an alert rule active for a decoy that no longer exists, or a decoy without a rule.

Coordinate with testers: tell your red team and external penetration testers the rules of engagement. Some organisations deliberately leave decoys unannounced to test detection; agree that decision with the test sponsor in writing. The Purple Teaming Guide describes joint exercises that validate decoy coverage.

Decision guidance by organisation size

Small teams without 24x7 cover: start with a handful of free-standing canary tokens and honey accounts that alert by email and phone to two named people. Focus on credentials in files and cloud keys. Skip honeynets.
Mid-sized SOCs: add native identity honeytokens, decoy hosts per segment and a register. Integrate alerts with the SIEM and case management.
Large enterprises: a deception platform with automated decoy rotation, broad endpoint seeding and integration with response automation makes sense once the basics are tested. Consider Affect operations only with dedicated staff.
Build or buy: building works for tokens and honey accounts; buying helps when you need hundreds of believable decoys kept in step with a changing estate.

Where identity fits

Most high-value decoys are identities: honey user accounts, decoy service accounts with SPNs, canary API keys, cloud access keys and session tokens. They work because modern intrusions are credential-led. Treat decoy non-human identities with the same discipline as real ones: zero permissions, documented owner, monitored use, and a clear entry in your NHI inventory flagged as a decoy so cleanup projects do not delete it. For agent workloads, see AI Agent Honeytokens and Canaries.

Measuring effectiveness

Metric	Definition	Target direction
Attack-path coverage	Share of prioritised attack paths with at least one decoy on the route	Up
Tested-alert rate	Share of decoys synthetically triggered and confirmed in the last quarter	Up, aim for all
Time from touch to triage	Minutes from decoy interaction to an analyst starting work	Down
False positive rate	Decoy alerts traced to a legitimate tool or process	Down after the pilot
Stale decoys	Decoys past their review date or failing believability checks	Down

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SC-26 Decoys	Components designed to attract and detect attacks
NIST SP 800-53 Rev. 5	SC-30 Concealment and Misdirection	Misdirection techniques to confuse adversaries
NIST SP 800-53 Rev. 5	SI-4 System Monitoring	Decoy alerts as monitoring inputs
NIST CSF 2.0	DE.CM-03, DE.AE-02	Monitoring personnel and technology use; analysing adverse events
MITRE D3FEND	D3-DUC, D3-DF, D3-DNR, D3-DO, D3-DST, D3-IHN, D3-CHN, D3-SHN	Decoy credentials, files, network resources, objects, session tokens and honeynets
MITRE Engage	Expose, Affect, Elicit	Strategic goals for adversary engagement

Common failure patterns

Decoys nobody watches. Alerts routed to a shared mailbox or a low-priority queue; the first real hit is found in a post-incident review.
Exclusion by subnet. Whitelisting the whole server VLAN to silence a scanner also silences an intruder on that VLAN.
Decoys with real permissions. A canary key or honey account that can actually do something is an attack surface. Grant nothing, and check it after every permission clean-up.
Obvious naming and stale attributes. Decoys that do not match local conventions or never change are spotted and avoided.
Register in the wrong place. A list of decoys in a shared wiki that an intruder can read.
No retirement process. Decoys outlive the systems they mimic and then confuse asset inventories and audits.

Practitioner checklist

Write a one-page objective covering goal, attack paths, alert owner and success measures.
Map each decoy to an ATT&CK technique and a D3FEND countermeasure.
Confirm telemetry for every decoy type is in the SIEM before deploying.
Create a restricted decoy register with owner, location, expected touches and review date.
Pilot quietly for two weeks, then add exclusions by identity rather than by network range.
Set decoy alerts to high severity with a written triage and containment runbook.
Synthetically trigger every decoy at least quarterly and record the result.
Ensure decoy credentials and keys hold no permissions, and recheck after access clean-ups.
Agree rules of engagement with red teams and testers.

Deception Technology Deployment Guide: Placing Decoys, Honeytokens and Alerts That Matter