Paste-ready deception technology requirements (decoys, lures, honeytokens, identity and cloud deception, SOC integration), vendor questions that separate products, and a weighted scoring rubric.
See the structure before you download. The Word file has every section listed below, ready to fill in.
The sections in the document, in order.
Use this deception technology RFP template when you're buying decoys, lures and honeytokens to detect attackers who are already inside your network, Active Directory or cloud accounts, and to send high-confidence alerts to your security operations center (SOC).
In 2026, deception is sold both as a standalone platform and as a module of EDR, XDR, identity threat detection and response (ITDR) and cloud security products, and the requirements in this template work for either.
It's written for the security operations, identity and infrastructure team running the evaluation, and it covers when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score the answers.
Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.
A deception evaluation involves security operations, identity, network, endpoint and cloud teams, and the most important early decision is which attacker behavior you want early warning of. The example schedule in this template runs about 11 weeks from kickoff to contract award; allow more if the proof of concept covers OT networks or several cloud providers.
Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.
| ID | Requirement | Priority |
|---|---|---|
| F1 | Decoys that emulate the systems an attacker expects to find in each network segment, such as Windows and Linux servers and workstations, file shares, databases, web applications, remote-access services and network devices, with host names, operating systems, services and banners that match our own. | Must-have |
| F2 | Automatic discovery of each segment's subnets, naming conventions, operating systems and services, used to generate decoys that blend in, with administrator review before anything is deployed. | Must-have |
| F3 | High-interaction decoys that run full operating systems an attacker can log in to, alongside emulated services, so attacker activity can be observed for longer. State which decoy types are emulated and which run a full operating system. | Nice-to-have |
| F4 | Lures (also called breadcrumbs) planted on real endpoints and servers that lead attackers to decoys, such as saved credentials, saved RDP and SSH connections, mapped drives, browser bookmarks and configuration files, without interfering with users' sign-in, applications or device performance. State the supported operating systems, and how lures are deployed (agent, our endpoint management or EDR tools, or scripts) and removed. | Must-have |
| F5 | Honeytokens that raise an alert when they are used or opened, including decoy credentials, decoy documents, database records, API keys and cloud access keys, each placeable where an attacker would look for them. | Must-have |
| F6 | Honeytokens planted in source code repositories, CI/CD pipelines and secrets managers [list], alerting when a planted secret is used. | Nice-to-have |
| F7 | Decoy Active Directory accounts (users, service accounts and computers) with no real privileges, including decoy service accounts with service principal names (SPNs), that alert on authentication attempts, Kerberoasting, AS-REP roasting and password spraying. State which techniques each decoy type detects and the data source used (domain controller logs, network traffic or an agent). | Must-have |
| F8 | Detection of Active Directory reconnaissance against decoy objects, and the option to return decoy results or hide sensitive accounts when an unauthorized process on an endpoint queries the directory. | Nice-to-have |
| F9 | Decoy accounts and groups in our cloud identity provider [name], with alerts on sign-in attempts and other use recorded in the provider's audit logs. | Nice-to-have |
| F10 | Cloud deception in [our cloud providers]: decoy storage buckets, compute instances, databases, secrets and access keys deployed through the provider's APIs, with alerts raised from the provider's audit logs. State the supported resource types per provider, whether Kubernetes clusters are covered, and how long an alert takes after a decoy is touched. | Must-have |
| F11 | OT, ICS and IoT decoys that emulate PLCs, HMIs, building controllers and other connected devices using the protocols in our environment (for example, Modbus, DNP3, BACnet, S7 or EtherNet/IP). Make this Must-have if OT networks are in scope. | Nice-to-have |
| F12 | An alert for every interaction with a decoy, lure or honeytoken, showing the source host and IP address, user account, process (where the source is a monitored endpoint), time, the decoy or token touched and what was attempted. | Must-have |
| F13 | Exclusions for legitimate activity, such as vulnerability scanners, asset discovery, backup and monitoring tools and authorized red-team tests, scoped by source and time window, with an audit record of every exclusion. | Must-have |
| F14 | A record of what happened on each decoy (connections, credentials tried, commands run and files transferred), with captured files available for download in a safe format such as a password-protected archive. | Must-have |
| F15 | Automatic analysis of files dropped on decoys in a built-in or integrated sandbox, and packet capture of decoy sessions. | Nice-to-have |
| F16 | Mapping of each alert to MITRE ATT&CK tactics and techniques, and an attack timeline that groups related events from the same source host or account. | Must-have |
| F17 | A coverage view showing where decoys, lures and honeytokens are deployed by site, network segment, cloud account and directory, and which segments or accounts have none. | Must-have |
| F18 | Central management to change, rotate or retire decoys, lures and honeytokens on a schedule or on demand, so they stay believable as our environment changes. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| T1 | Placement of decoys in many network segments from a small number of appliances or virtual machines (for example, through VLAN trunking), with lightweight sensors for remote sites and no component in the production traffic path. State how many decoys and segments each appliance or sensor supports. | Must-have |
| T2 | A clear description of deployment options for the management console (vendor-hosted, customer-hosted or both), listing every component we would host with its sizing and resource use. | Must-have |
| T3 | A fully on-premises deployment that works without internet connectivity, for air-gapped, OT or classified networks. Make this Must-have if such networks are in scope. | Nice-to-have |
| T4 | Containment of every decoy: decoys can't be used to reach production systems or the internet, and outbound connections from decoys are blocked or tightly controlled. Describe how a decoy an attacker has taken over is prevented from becoming a pivot point. | Must-have |
| T5 | Decoys that respond like real systems to common reconnaissance and fingerprinting techniques. Describe how and how often you test decoys against attacker tools that try to identify them. | Must-have |
| T6 | Health monitoring with an alert when a decoy stops responding, a sensor or appliance goes offline, or lures are missing from endpoints that should have them. | Must-have |
| T7 | Support for [number] sites, [number] network segments, [number] endpoints with lures and [number] cloud accounts, including an architecture for sites with limited bandwidth. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| I1 | Near-real-time forwarding of alerts and audit logs to our SIEM via syslog (CEF or LEEF) and a REST API, in a documented schema. | Must-have |
| I2 | Integration with our EDR or XDR platform [name] that adds process and user context from the source host to each alert, and isolates that host automatically or after analyst approval, as we choose. | Must-have |
| I3 | Integration with our SOAR platform and ticketing (ITSM) system through an API or webhooks, with documented actions for opening cases and starting response playbooks. | Must-have |
| I4 | Response actions through our firewalls and network access control (NAC) to block or quarantine the source IP address or device. | Nice-to-have |
| I5 | Export of indicators from decoy interactions (IP addresses, file hashes, credentials tried and tools seen) to our threat intelligence platform in STIX 2.1 over TAXII, or through an API. | Nice-to-have |
| I6 | A documented API and infrastructure-as-code support (for example, a Terraform provider) for creating and retiring decoys and honeytokens, so cloud decoys can be deployed with our standard account provisioning. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| S1 | A current SOC 2 Type II report and ISO/IEC 27001 certification covering any vendor-hosted components, available under NDA. | Must-have |
| S2 | FedRAMP authorization at the required impact level, or equivalent regional certifications for public-sector use. Make this Must-have if you are a public-sector buyer. | Nice-to-have |
| S3 | Least-privilege access to our environment: a documented list of the permissions the product needs in Active Directory, cloud accounts and endpoint tools, with any credentials it stores encrypted and rotatable. | Must-have |
| S4 | Administrator access through SSO (SAML 2.0 or OIDC) with MFA, role-based permissions, and an audit log of every configuration change, including the creation and removal of decoys, lures, honeytokens and exclusions. | Must-have |
| S5 | Role-based visibility that limits who can see where decoys, lures and honeytokens are placed, so their locations aren't known to all IT staff. | Must-have |
| S6 | Control over captured data: what the product records from attacker sessions, where it is stored, how long it is kept, and export at any time. Captured data can include real credentials and personal data, so state the region and retention options. | Must-have |
| S7 | A published vulnerability disclosure process and committed timelines for fixing security flaws in appliances, sensors, decoy images and agents, with direct notice when a fix needs action on components we host. | Must-have |
| S8 | A data processing agreement, a current list of sub-processors, and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. | Must-have |
| ID | Requirement | Priority |
|---|---|---|
| M1 | A discovery and design phase that produces a written deception plan: the attack paths to cover, placement of decoys, lures and honeytokens by segment, directory and cloud account, exclusions, and alert routing. | Must-have |
| M2 | A phased rollout that starts with a pilot, with the effort expected from our network, endpoint, identity and cloud teams at each phase. | Must-have |
| M3 | Identification of who delivers the implementation (vendor, partner or both) and the named team's experience with deployments of similar size and environment. | Must-have |
| M4 | A tuning period to exclude legitimate activity before alerts go to the live SOC queue, plus alert-handling runbooks for our analysts. | Must-have |
| M5 | A service-level agreement for the availability of any vendor-hosted console or service, with service credits, and 24×7 support for critical issues with response-time targets by severity. State the targets. | Must-have |
| M6 | A stated split of ongoing work between us and the vendor: refreshing decoys and lures, adding coverage for new segments and cloud accounts, and updating decoy images. | Must-have |
| M7 | Support for periodic testing of deception coverage, such as an exercise with our red team or a penetration tester, with a written report of which steps were detected. | Nice-to-have |
| M8 | Training for administrators and SOC analysts, with documentation for investigating each alert type. | Nice-to-have |
| ID | Requirement | Priority |
|---|---|---|
| C1 | Pricing broken down by metric (per protected endpoint, per decoy, per network segment, per site or per cloud account) and term, showing list price, discount and net price. | Must-have |
| C2 | A clear statement of what is included and what is an add-on, covering identity deception, cloud deception, OT decoys, high-interaction decoys, sandbox analysis and appliances. | Must-have |
| C3 | Prices for adding sites, segments, endpoints or cloud accounts mid-term, co-terminated with the main agreement. | Must-have |
| C4 | A cap on price increases at renewal. State the cap. | Must-have |
| C5 | If deception is a module of a broader platform, whether it can be bought and renewed on its own, and what happens to it if we change platform edition or stop using the platform. | Must-have |
| C6 | A proof of concept at no charge, with the vendor's engineering support. | Nice-to-have |
| C7 | Exit terms covering removal of every lure, decoy account and honeytoken from our environment, export of alert history and captured data, and transition assistance. | Must-have |
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.
| Criterion | Weight | What a strong response shows |
|---|---|---|
| Decoy, lure and honeytoken coverage and realism | 20% | Decoys that match your environment and hold up in a red-team test, lures for every endpoint type you run, and honeytokens where attackers look for credentials and data. |
| Identity and cloud deception | 15% | Decoy accounts that detect the Active Directory attacks you care about, plus decoys and honeytokens in your cloud providers, shown working in the proof of concept. |
| Alert fidelity and investigation context | 15% | Few alerts from legitimate tools after tuning, and alerts that carry the source host, account, process and attacker activity your analysts need to act. |
| SOC integration and response | 15% | Alerts in your SIEM in near real time, EDR context and host isolation, and SOAR and ticketing actions that work with your tools. |
| Deployment, scale and ongoing effort | 10% | A clear placement architecture for your sites and segments, a coverage view, and a realistic split of maintenance work between you and the vendor. |
| Platform safety and security | 10% | Contained decoys, least-privilege access to your directories and cloud accounts, restricted visibility of decoy locations, and a credible patching record. |
| Commercials and total cost | 15% | Transparent pricing, identity, cloud and OT add-ons priced up front, a renewal cap, and exit terms that cover removing every lure and decoy account. |
| Total | 100% |
Scoring scale
Your detection goals and scope (sites, network segments, endpoints, directories and cloud accounts); requirements for decoys, lures, honeytokens, identity and cloud deception, alert content and SOC integration, each marked Must-have or Nice-to-have; questions about decoy realism, containment and exclusions for legitimate tools; security, support and SLA terms; a pricing table; and the rubric you'll score with. This template includes all of them.
A honeypot is a single decoy system, often set up and maintained by hand. Deception technology creates and manages many decoys at once across network segments, identity systems and cloud accounts, plants lures and honeytokens on real systems to lead attackers to them, and sends alerts into the tools your SOC already uses. The detection idea is the same: no legitimate user has a reason to touch a decoy, so any interaction is worth investigating.
In 2026, deception is sold both ways: as a standalone platform, and as a feature or module of EDR, XDR, identity threat detection and response (ITDR) and cloud security products. A module can be quicker to deploy and uses a console and agent you already run, but check which decoy types it offers and whether it covers devices and networks without that vendor's agent. A standalone platform may cover more environments, such as OT networks, at the cost of another console and contract. This template works for either, and requirement C5 covers how module licensing works.
Honeytokens are fake items that raise an alert when someone uses or opens them: credentials, documents, database records, API keys or cloud access keys. Lures, also called breadcrumbs, are traces planted on real endpoints, such as saved credentials or saved connections, that point an attacker toward a decoy. Together they can catch an attacker who never scans the network, because the attacker meets them while searching a compromised system for credentials and data.
The example schedule in this template runs about 11 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of concept. Allow longer if OT networks or several cloud providers are in scope, or if you need to arrange a red-team exercise for the proof of concept. Rollout follows the award, starting with a pilot.
Paste-ready requirements for finding and securing service accounts, API keys, tokens, workload identities and AI agents, with vendor questions, a scoring rubric…
Paste-ready ZTNA requirements (per-app policy, device posture, agent and agentless access, connectors, VPN migration), vendor questions that separate products, and a weighted…
Paste-ready requirements for immutable backup storage and cyber recovery vaults (object lock, isolation, multi-person approval, clean-room recovery), vendor questions and a weighted…
Please provide your feedback below.
"*" indicates required fields