Threat agnostic deployment places decoys by mapping existing services and making honey services resemble them closely. Service agnostic deployment creates decoys from endpoint events and attack patterns, so they can appear even when the protected service does not already exist. The first is service driven, while the second is behavior driven and more adaptive.
How the deployment model changes what the decoy is trying to imitate
Threat agnostic deception is built around the service landscape that already exists. It studies real services, then places decoys that closely resemble them so an intruder cannot easily tell the difference. Service agnostic deception starts from observed endpoint behavior and attack patterns instead, which makes it useful for environments where there is no mature service to mirror or where the defender wants a decoy that tracks hostile activity more directly.
The practical difference is not just where the decoy sits, but what drives its design. Threat agnostic placement is service driven, so the fidelity of the honey service depends on how well the real service inventory is understood. Service agnostic placement is behavior driven, so the decoy can be generated from what the attacker does, which gives defenders more flexibility when the exposed system set changes quickly or is only partially known.
Because of that, the first model tends to favor close resemblance and infrastructure realism, while the second tends to favor adaptability and broader coverage. In both cases, the goal is to create a believable interaction point, but the source of truth is different: existing services for one, attack behavior for the other.
Where each approach fits in a real environment
Threat agnostic deception works best when the environment is stable enough to model. If you already know which services matter and can accurately replicate them, this approach gives you a more natural look and feel for an intruder moving through the network. It is often the better choice when the objective is to make fake services blend in with genuine production patterns.
Service agnostic deception is stronger when the defender cannot rely on a clean service map. It can create decoys even where the protected service does not yet exist, which makes it useful for dynamic estates, fast-changing platforms, and situations where the defender wants to seed traps based on attacker activity rather than on a fixed service catalog.
That difference matters operationally. A service driven model can be more precise, but it can also inherit blind spots from incomplete service discovery. A behavior driven model is more adaptive, but it demands better telemetry and stronger logic for deciding which endpoint events or attack patterns should trigger decoy creation.
What practitioners should expect from fidelity, coverage, and maintenance
Threat agnostic deception usually requires more effort up front to imitate the right service shape, naming, protocols, and interaction flow. If that fidelity is too low, the decoy can be exposed quickly. Service agnostic deception shifts more of the burden to the detection logic and the response pipeline, because the system has to interpret endpoint events and decide when and how to spin up convincing bait.
That trade-off changes maintenance too. Service agnostic decoys can be easier to scale across a changing estate because they are less dependent on an exact mirror of every live service. Threat agnostic decoys can be easier to reason about when the service footprint is well understood, but they need ongoing alignment with the real environment so they do not drift away from production reality.
For a deeper view of how deception fits into broader NHI and machine-credential attack paths, see The 52 NHI Breaches Report, which shows how attackers routinely abuse service account, secrets, and lateral movement opportunities once initial trust is established.
Risk and Threat Considerations
Deception only works if the attacker believes the decoy is part of the real environment. If the placement logic is too obviously tied to existing services, the trap may be easy to fingerprint; if it is too loosely tied to observed behavior, the decoy may look incoherent and fail to engage the intruder long enough to generate useful signals.
Failure mechanism: Threat agnostic deployments can fail when the service model is incomplete or stale, while service agnostic deployments can fail when endpoint telemetry is noisy or too generic to produce believable decoys. In either case, the adversary may detect the mismatch and avoid the deception layer.
Impact: The result is wasted defensive effort, lower-quality alerting, and missed opportunities to observe reconnaissance, credential use, or lateral movement before a real asset is reached.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1583 — Acquire Infrastructure | Deception deployment depends on believable staging and infrastructure patterns. |
| T1595 — Active Scanning | Threat agnostic and service agnostic traps are often validated through reconnaissance and scan behavior. | |
| Recommendation — Map decoy infrastructure to likely attacker staging patterns and monitor for reconnaissance. Use scan and reconnaissance detections to trigger or tune deception assets. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Deception relies on telemetry that detects interaction with decoys. |
| Recommendation — Instrument decoys to surface anomalous interactions into continuous monitoring. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Decoy value depends on logging and preserving attacker interaction evidence. |
| Recommendation — Centralize and protect decoy interaction logs for investigation and alerting. | ||
Practitioner Guidance
What to prioritise: Use threat agnostic placement when you have a reliable service inventory and want maximum realism around known assets. Use service agnostic placement when the estate changes often, when the service picture is incomplete, or when you need decoys that can be generated from attacker behavior rather than service discovery.
What to verify: Check that the decoy’s network exposure, naming, timing, and interaction pattern are internally consistent. For service agnostic deployments, also verify that the triggering endpoint events are specific enough to avoid creating noisy or generic bait.
Practitioner takeaway: The right choice depends on what you trust more, your service map or your behavior telemetry. If service knowledge is strong, realism wins; if the environment is fluid, adaptability usually wins.
Related resources from NHI Mgmt Group
- How should security teams choose between threat agnostic and service agnostic deception deployment?
- What is the difference between deployment profiles and service roles in identity platform operations?
- What is the difference between a quickstart ECS deployment and a production-ready ECS deployment for an authorization service?
- What is the difference between a private local AI deployment and a public cloud AI service from a security perspective?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
