A deception platform is a map of every trap in your estate plus the credentials to plant more, so an attacker who reaches it can avoid every decoy, mute every alert or use the platform as a way in. To place decoys and breadcrumbs, the platform typically holds write access into the directory, API keys into endpoint tools and cloud accounts, network presence in many segments and a management server that talks to all of it. The NCSC, reporting on its cyber deception trials, warns that a misconfigured deception tool can miss threats, give a false sense of security or even create openings for attackers. This guide is for SOC leads, detection engineers and platform owners who run a deception platform. It covers admin roles, the platform's own identities, decoy containment, keeping the platform itself hidden, its logs and its lifecycle. It is vendor-neutral: confirm exact setting names in your vendor's documentation. For what to deploy and where, see the Deception Technology Guide and the Deception Technology Deployment Guide.
Key takeaways
- The console is the attacker's cheat sheet. It lists every decoy and honeytoken, so access to it burns the whole programme; restrict it like a high-impact admin system.
- Deployment integrations are the most powerful credentials. Accounts that create directory objects or push breadcrumbs through endpoint tools can also create real persistence, so scope them tightly and separate them from read-only monitoring.
- Decoys must be dead ends. Contain decoy hosts so an attacker who compromises one cannot reach production, the management server or the internet.
- The platform must not give itself away. Management traffic, agent names and default decoy images can reveal the deception layer; check what an intruder would see.
- Alert on the platform going quiet. A muted alert route or a stopped decoy looks the same as no intrusion, so monitor the platform from outside itself.
What the platform holds and can do
Deception products differ, but most combine a management server or SaaS console, decoy hosts and services, deployment integrations and an alert pipeline. The table describes a common architecture.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Management console | Decoy inventory, honeytoken list, alert rules, suppression lists, roles | Learns every trap, suppresses alerts, adds exclusions for their own hosts | SSO with phishing-resistant MFA, need-to-know roles, admin from privileged access workstations |
| Decoy hosts and services | Emulated or real operating systems and services in production segments | A foothold or pivot if a decoy is a full system with outbound reach | Egress blocked, no routes to production or the management plane, hardened images |
| Directory deployment account | Create and modify decoy users, groups, computers and service principal names | Creates real accounts or changes real groups for persistence | Write rights limited to a dedicated organisational unit, logged, just in time |
| Endpoint and cloud deployment integrations | API keys to push breadcrumbs, files and fake credentials to endpoints or cloud accounts | Runs actions on every managed endpoint or reads cloud configuration | Narrowest API role, per-integration keys, IP restriction, rotation |
| Network presence (trunks, virtual interfaces) | Interfaces in many VLANs or subnets | Bridges segments that should be separate | No forwarding between interfaces, change control on new segments |
| Alert pipeline | Routes to SIEM, SOAR, chat and paging | Mutes or redirects the highest-fidelity alerts you have | Write-only outbound credentials, heartbeat test alerts, alert on route changes |
Treat the console with the same care as other high-impact admin systems. The UK NCSC tiers guidance describes tier 0 as the root of trust and warns against administering a higher tier from a lower-tier device; a deception console that can write to the directory belongs at least in the tier of the systems it writes to. See the Tiered Administration and Enterprise Access Model Guide.
Admin roles and need-to-know
Deception works best when few people know where the traps are. The NCSC trials blog reports that 90% of participants said they would not publicly announce their use of cyber deception, so as not to tip off attackers. The same logic applies inside the organisation.
| Role | Can do | Should not do |
|---|---|---|
| Platform administrator | Roles, integrations, network settings, updates | Edit alert suppression without approval |
| Deception engineer | Design and place decoys and honeytokens, test triggers | Change roles or integration credentials |
| SOC analyst | See alerts with the decoy context needed to respond | Browse the full decoy inventory |
| Approver | Approve suppressions, exclusions and new deployment integrations | Approve their own change |
| Auditor | Read configuration history and audit logs | Change anything |
- Authentication: SSO through your identity provider with phishing-resistant MFA, local accounts disabled or vaulted once SSO works, and one documented break-glass account. The CISA and FBI Secure by Demand guide suggests buyers ask whether SSO comes at no extra cost and MFA is on by default. See the Break-Glass Account Guide.
- Admin devices: administer the platform from privileged access workstations. The NCSC recommends that high-risk actions such as changing security controls are performed only from such devices, with just-in-time privileges. See the Privileged Access Workstations Guide.
- Suppression is a privilege: an alert suppression or "known scanner" exclusion is a permanent hole in your most reliable detection. Require two people for it; NCSC notes that privileged access management makes it harder for one person to make a mistake or act maliciously alone.
- Review: review roles every quarter (our recommendation) and on every leaver, and treat a departing deception engineer as a reason to rotate some decoy placements.
Deployment identities and integrations
| Identity | Needs | Avoid | Credential pattern |
|---|---|---|---|
| Directory deployment account | Create and manage objects in a dedicated decoy organisational unit or a defined set of objects | Domain admin, or rights over real privileged groups | Managed service account or vaulted password, logon restricted to the management server |
| Directory read account | Read structure to make decoys believable | Write rights of any kind | Separate from the deployment account |
| Endpoint tool integration | Place files or breadcrumbs on endpoints through the endpoint tool's API | A role that can also run arbitrary scripts or isolate hosts | One API key with the narrowest documented role, IP restricted |
| Cloud deployment role | Create decoy resources and keys in designated accounts or projects | Organisation-wide administrator | Federated role assumption with external ID; no long-lived access keys |
| Outbound alert credentials | Send events to SIEM, SOAR or paging | Read access to those systems | Write-only token, rotation, destination restricted |
- Separate read from write: the account that reads the directory to model believable decoys should not be the account that creates objects.
- Mark decoys in the inventory, not in the object: decoy identities should be flagged in your NHI inventory so clean-up projects do not delete them, but not with an obvious attribute an intruder can query. See the Honeytokens and Canary Credentials Guide.
- Decoy credentials must not work: honey accounts and canary keys should carry no real permissions, so a decoy that is used produces an alert, not access.
- Constrain tokens: for OAuth-based integrations, RFC 9700 recommends sender-constrained tokens (mutual TLS or DPoP), audience restriction and asymmetric client authentication. Use them where supported.
- Inventory them: record each integration with owner, scope and expiry. See the Service Account Security Guide.
Containing decoys and hiding the platform
- No outbound reach: decoy hosts should not reach the internet or production systems. Allow only the specific management flows the product documents, and alert on anything else. A decoy that an attacker can use as a launch point fails the basic safety test the Honeypot deployment guide sets out.
- Isolate the management plane: place the management server in an admin segment that decoys can reach only on the documented port, never the reverse for interactive access.
- No forwarding across segments: where decoys have interfaces in many VLANs, confirm that the appliance or host cannot route between them, and review it on every new segment.
- Harden decoy images: emulated services and full decoy operating systems still need updates. Apply vendor security updates promptly and subscribe to the vendor's security advisories; a vulnerable decoy can be a real foothold.
- Check the tells: review what an intruder sees: host names, MAC address prefixes, default banners, identical uptimes, management traffic patterns and agent process names. Ask the vendor which defaults to change, and test with your red team.
- Synthetic data only: decoy files and records must be fake, so that a stolen decoy is never a reportable data breach.
The platform's own logs and alert integrity
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Decoy inventory exported or viewed in bulk | Someone is mapping the traps | Always |
| Alert suppression, exclusion or allow-list change | Permanent blind spot | Always, with approver |
| Alert route or destination changed or disabled | The highest-fidelity alerts go nowhere | Always |
| Role assignment, new local account, SSO change | Persistence in the console (T1078) | Always |
| Deployment integration credential added or changed | Added credentials (T1098.001) | Always |
| Decoy stopped, deleted or unreachable | Loss of coverage (T1685) | Always for decoys on key attack paths |
| Directory objects created by the deployment account outside the decoy scope | The integration is being abused | Always |
- Synthetic triggers from outside: touch a sample of decoys on a schedule (weekly is our suggestion) from a test host, and alert in the SIEM if the expected alert does not arrive. This catches muted routes and stopped decoys that the platform itself will not report.
- Export audit logs elsewhere: stream console audit logs to a SIEM or archive that deception administrators cannot change, in line with NIST SP 800-53 AU-9(2) and AC-6(9). Secure by Demand asks SaaS providers to keep security logs available for at least six months at no additional charge. See the Log Management and Retention Guide.
- Cross-check the directory: reconcile objects created by the deployment account with the decoy register; anything outside it is a red flag.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions (SSO, MFA by default, logs in the base product, vulnerability disclosure policy, SBOM). Ask for the permission list per integration, how decoys are contained, which defaults reveal the platform, and vendor staff access to the decoy inventory. See the Deception Technology Buyer's Guide. |
| Deploy | Set up SSO, roles and audit export first; create read and write directory identities separately; build containment rules before the first decoy; confirm alert routes with synthetic triggers. |
| Run | Quarterly reviews of roles, integrations and suppressions; decoy image updates; weekly synthetic triggers; red team checks for tells; register reconciliation. |
| Respond | If the console is suspected compromised, assume every decoy is known: rotate integration credentials, review suppressions and directory changes, and redeploy decoys in new places once the platform is trusted again. |
| Retire | Remove decoy hosts, directory objects, breadcrumbs and canary keys through change control (orphaned decoys confuse future incident response), revoke integrations, export the audit history you need and obtain written confirmation of data deletion. |
Roll back a hardening change, such as narrowing the deployment account to one organisational unit, by keeping the previous delegation documented and re-granting only the specific right a feature reports missing.
Detection and measurement
Metrics that show the platform itself is protected:
- Number of people who can view the full decoy inventory (target: the deception team only).
- Synthetic trigger success rate (target 100%), and time from a missed trigger to detection.
- Alert suppressions without an owner or past their expiry (target zero; our suggested expiry is 90 days).
- Decoy hosts with outbound reach beyond documented flows (target zero, verified by scan).
- Percentage of integrations using federated or certificate credentials rather than static keys.
- Directory objects created by the deployment account that match the register (target 100%).
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Console roles and privileged accounts | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Deployment integration credentials | IA-5, SC-12 | PR.AA-01 | T1098.001 Additional Cloud Credentials |
| Decoy containment | AC-4, SC-7 | DE.CM-01 | T1199 Trusted Relationship (pivot through a trusted component) |
| Audit log and alert integrity | AU-9, AU-9(2), AC-6(9), SI-4 | PR.PS-04 | T1685 Disable or Modify Tools |
| Vendor and supply chain | SA-9 | GV.SC-07 | T1195 Supply Chain Compromise |
Common failure patterns
- Domain admin for deployment: the deployment account gets broad directory rights during a proof of concept and keeps them.
- Decoys with internet access: a full operating system decoy can browse out, so an attacker who lands on it has a working beachhead.
- Everyone sees the map: the decoy inventory is visible to the whole SOC and exported to a shared spreadsheet.
- Silent alert routes: a SIEM migration or webhook change breaks the alert path and nobody notices until a red team exercise.
- Obvious defaults: decoys keep vendor default names or banners that an intruder can fingerprint.
- Orphaned decoys after retirement: honey accounts and canary keys remain long after the platform is gone, with nobody watching them.
Practitioner checklist
- Enforce SSO with phishing-resistant MFA on the console and keep one tested break-glass account.
- Restrict the full decoy inventory to the deception team and give analysts alert context only.
- Split directory read and write identities and confine write rights to a dedicated scope.
- Give endpoint and cloud deployment integrations the narrowest API role, with per-integration keys and expiry.
- Block decoy egress to the internet and production, and isolate the management plane.
- Remove default names, banners and other tells, and test with your red team.
- Require two approvers for suppressions and alert route changes, and run weekly synthetic triggers from outside the platform.
- Export audit logs to a store deception administrators cannot change.
- Retire decoys, breadcrumbs and canary keys in full when the platform is removed.
Standards and references
- NCSC: Cyber deception trials: what we've learned so far
- NCSC: Risk manage administration using tiers
- CISA and FBI: Secure by Demand Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- MITRE ATT&CK: T1685 Disable or Modify Tools
Related NHI Mgmt Group resources: Deception Technology Guide · Deception Technology Deployment Guide · Honeytokens and Canary Credentials Guide · Honeypot deployment · Securing the identity threat detection and response (ITDR) tool itself