Deception platforms promise near-zero false positives, but many end up as a few stale decoys that no attacker ever touches and no analyst ever checks. A deception platform places decoy hosts, credentials, files, cloud keys and directory objects where attackers look, and alerts when any of them is used. Products differ in which decoy types they can create, how believable and maintainable those decoys are, how they reach endpoints, identity systems, cloud and OT, and how alerts reach the SOC. This vendor-neutral deception technology buyer's guide is for SOC leads, detection engineers and procurement teams writing a deception platform RFP or comparing options, and ends with a proof of concept that tests decoys against real attacker techniques. For how deception works and how to deploy it, see the Deception Technology Guide.
Key takeaways
- Strategy before product. The NCSC's deception trials found that "without a clear strategy organisations risk deploying tools that generate noise rather than insight"; decide which attacker behaviours you want to catch before choosing a deception platform.
- Credentials are the best bait. Weight decoy credentials, honeytokens and identity decoys heavily, because credential theft precedes most lateral movement and cloud compromise.
- Believability needs maintenance. MITRE Engage warns that "Deception is a process, not a fire-and-forget technology stack"; test how a product keeps decoys realistic as your estate changes.
- The platform itself is privileged. Creating decoy accounts in Active Directory, objects in cloud tenants and lures on endpoints needs write access; scope and monitor those integration identities.
- Test, do not trust. Run credential dumping, Kerberoasting, share crawling and stolen key use in the proof of concept, and measure which decoys fire, how fast and with what context.
Define requirements
NIST SP 800-53 Rev. 5 control SC-26 Decoys asks organisations to include components "specifically designed to be the target of malicious attacks" "for detecting, deflecting, and analyzing such attacks", and SC-30 Concealment and Misdirection covers techniques to "confuse and mislead adversaries". NIST SP 800-160 Vol. 2 Rev. 1 treats Deception as a cyber resiliency technique: "Mislead, confuse, hide critical assets from, or expose covertly tainted assets to the adversary". Start by writing down which of these outcomes you are buying: early detection, threat intelligence on attacker behaviour, or slowing attackers down. Then record the environment.
- Behaviours to detect: for example network service discovery (ATT&CK T1046), credentials in files (T1552.001), Kerberoasting (T1558.003), credential dumping, share crawling, use of stolen cloud keys and lateral movement into a crown jewel segment. The NCSC advises organisations to "identify strategic gaps before choosing a product".
- Zones to cover: each Active Directory forest and Entra ID tenant, server and user subnets, cloud accounts and subscriptions, Kubernetes clusters, source code and CI systems, SaaS, and OT networks. List which zones have strong monitoring already, so decoys fill gaps rather than duplicate.
- Who will operate it: an in-house SOC, a managed detection provider, or deception as a service where the provider designs, deploys and watches the decoys. Agree who receives alerts at 3 a.m.
- Constraints: no agents on some hosts, change control for directory objects, data residency for decoy telemetry, OT safety rules (passive only), and a small, need-to-know group who knows where decoys are. The NCSC found 90% of trial participants would not announce their use of deception.
| Platform category | What it provides | Fits when | Watch for |
|---|---|---|---|
| Honeytoken and canary services | Decoy credentials, keys, documents, URLs and DNS names that alert when used (D3FEND D3-DUC, D3-DF) | You want early warning quickly with low effort | Coverage limited to token types offered; alerts need routing into your SIEM |
| Distributed deception platform | Central management of decoy hosts and services, lures on endpoints, decoy directory objects and cloud decoys across many zones (D3-DE, D3-DNR, D3-DO) | Large or flat estates, several forests or clouds, a SOC that can act on engagement data | Deployment and integration effort; privileged connectors |
| Deception features in existing tools | Honeytoken tagging or decoy lures inside identity threat detection, endpoint or network products you already own | You want identity decoys without another console | Narrow decoy range; check what is included in your licence tier |
| Deception as a service | A provider designs, deploys, tunes and monitors decoys, often with the platform included | Small teams without 24x7 coverage | Provider access to your directory and cloud; response times in the contract |
| Self-built honeypots | Open source honeypots and scripted honeytokens maintained in-house | Engineering capacity and narrow, well-defined use cases | Patching, believability and containment are all yours |
Deception technology pricing follows a few models: per protected endpoint or user, per network segment, VLAN or decoy count, per cloud account or identity domain, a platform tier with token or decoy limits, or a managed service subscription. Ask for all-in costs including decoy hosting compute, cloud logging needed for key decoys, SIEM ingest, OT sensors and professional services, and what happens to price when you add a forest, cloud account or site. Small organisations usually get most value from honeytokens and identity decoys in tools they already run; large organisations with many zones are the main market for distributed platforms.
Evaluation criteria
Use these criteria for deception platform evaluation and for a like-for-like deception platform comparison across deception technology vendors and managed providers; the same rows apply when comparing honeytoken vendors with full platforms. There is no single best deception technology, only the best fit for your zones and team. Weight the criteria to your requirements. An illustrative split: 25% decoy coverage and believability, 20% identity and honeytoken coverage, 15% alert quality and SOC integration, 15% deployment and maintenance, 10% safety and containment, 15% commercial terms and service.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Decoy coverage | Decoy hosts and services for your operating systems and applications; decoy directory objects, files, shares, cloud resources and OT devices; mapping to D3FEND Deceive techniques you can verify | One or two decoy types sold as full coverage; no cloud or OT option |
| Honeytoken coverage | Honeytoken platform capabilities for AD accounts and service principal names, Entra ID and other IdP accounts, cloud access keys, SaaS and CI tokens, session cookies (D3-DST), database rows and documents; a register of every token | Document tokens only; no identity or cloud key tokens; no register, so decoys get mistaken for real leaks |
| Believability | Decoys generated from your own naming conventions, operating system builds and directory structure; automatic refresh as the estate changes; lures placed where attackers look (credential stores, recent files, saved connections) | Default host names and banners; static decoys that age visibly |
| Deployment model | Agentless options for lure placement; clear permissions per integration; staged rollout per zone; one-click withdrawal of any decoy | Agents required everywhere; domain admin rights requested for setup |
| Alert quality and context | Each alert names the decoy, source host and identity, what was attempted and the attacker's path; mapping to ATT&CK technique IDs; low benign hit rate after tuning | Alerts with an IP address only; benign scanner hits that cannot be excluded narrowly |
| SOC integration and response | Documented SIEM schema, SOAR actions, integration with EDR and identity platforms to contain the source host or account, with approval and audit | Email alerts only; automated blocking with no approval or rollback |
| Engagement data | Optional high-interaction decoys that record attacker commands and tools safely, with export for threat intelligence | No containment design for high-interaction decoys |
| Safety and containment | Decoys isolated from production, outbound traffic denied except to the collector, no real data in decoys, as SC-26 expects "supporting isolation measures" | Decoy hosts with internet access; decoy accounts with real permissions |
| Platform security | Scoped, expiring service credentials for AD, cloud and EDR integrations; SSO and MFA for the console; customer-controlled logs of platform actions | Shared long-lived admin keys; vendor support access you cannot see |
| Commercial and service | Clear licence metric, all-in costs, data location, exit plan that removes every decoy and lure | Pricing that rises sharply with each new zone; no decoy removal on exit |
The platform's integration identities are high-value non-human identities: an account that can create users in your directory or objects in your cloud is a target in its own right. See the Service Account Security Guide. When a decoy credential fires, the response follows the same steps as a real leak; see the Leaked Credential Response Playbook.
Questions to ask vendors
- Which decoy types do you support natively in each of our zones (AD, Entra ID, AWS, Azure, Google Cloud, Kubernetes, SaaS, OT), and which need custom work?
- Which honeytoken types do you offer for identities and keys, and how do we keep a register so secret scanning and incident teams can tell decoys from real leaks?
- How are decoys made to match our naming, builds and directory structure, and how are they refreshed as the estate changes?
- What permissions does each integration need, are they scoped and expiring, and where are those credentials stored?
- For three ATT&CK techniques we name, which decoys fire, what does the alert contain, and how long does it take to reach our SIEM?
- How do you prevent a high-interaction decoy being used to attack us or third parties?
- Can we remove any single decoy, and every decoy and lure at contract end, and prove it?
- For deception as a service: who watches alerts, what are the response commitments, and what access do your staff have to our environment?
- What is the licence metric, and how does price change when we add a forest, cloud account, site or OT network?
Red flags
- "Set and forget" positioning that contradicts the Engage view that deception is a process.
- Coverage claims mapped to ATT&CK or D3FEND that cannot be shown as specific decoys and alerts.
- Requests for domain admin or cloud owner rights to install or run the product.
- Decoys with real permissions or outbound internet access; the NCSC warns that "misconfiguration can introduce new vulnerabilities".
- No way to narrowly exclude a benign scanner without suppressing the decoy for everyone.
- No outcome metrics; the NCSC found these "were not readily available and require development", so ask how the vendor will help you measure.
Proof of concept
Treat the proof of concept as a deception platform proof of value: it should show detections you would otherwise miss, not just a working console.
- Scope: one AD domain or Entra ID tenant, one server subnet, one cloud account and, if relevant, one OT segment in passive mode. Agree rules of engagement and a need-to-know list.
- Deploy and baseline: let each candidate place decoys and lures for two to four weeks with alerts going only to the detection team. Record every benign hit and how it was tuned out.
- Run the techniques: using a controlled red team or adversary emulation, perform network service discovery (T1046), search for credentials in files (T1552.001), Kerberoast (T1558.003), dump credentials on a test host, crawl file shares and use a harvested cloud key. Score each candidate on the same runs.
- Measure: which decoys fired, time from touch to SIEM alert, alert context, benign alert rate per week, and analyst time to triage.
- Test response and rollback: contain the source host or account through the integrations with approval switched on, then reverse it; withdraw a decoy and confirm it is gone everywhere.
- Review effort and cost: record engineering hours to deploy and refresh decoys, and model cost for full rollout.
After go-live, track coverage of priority zones, time to alert, alert precision, red team detection rate and decoy health (share of decoys that passed their last validation).
Standards and references
- MITRE D3FEND: Deceive tactic
- MITRE Engage: Engage Matrix
- MITRE Engage: Engage for vendors
- NIST: SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems
- NIST SP 800-53 Rev. 5 (CSF Tools): SC-26 Decoys
- NIST SP 800-53 Rev. 5 (CSF Tools): SC-30 Concealment and Misdirection
- NCSC: Cyber deception trials, what we've learned so far
- MITRE ATT&CK: T1558.003 Kerberoasting
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Deception Technology Guide · Leaked Credential Response Playbook · ITDR Buyer's Guide · Detection Engineering Guide · MITRE D3FEND Guide