What Is a Honeypot?

A honeypot is a sacrificial computer system designed to attract cyberattacks. It mimics a real target – a customer database, an authentication server, an industrial control system – but contains no genuine business value. Its purpose is to lure attackers, monitor their behavior, and gather intelligence about how they operate. The term originates from espionage tradecraft, where a “honey trap” describes a setup that compromises a target through false attraction.

In cybersecurity, the honeypot operates on the same principle. The system looks legitimate – applications running, data appearing accessible, services responding to probes – but every interaction is recorded. Attackers who think they’ve found a vulnerable target are actually walking into surveillance. Their tools, techniques, and objectives become observable in ways that real production systems would never reveal.

This article covers what honeypots are, the categories that exist in 2026, the specific scenarios where they remain valuable, and the architectural shift that has changed where they fit in modern security programs. The shift is significant: in environments built on Zero Trust Network Access (ZTNA), the assumptions that originally made honeypots central to detection have changed. The honeypot is no longer the primary tool for catching attackers – but it has not disappeared. It has been redefined.

How Honeypots Work

A honeypot looks like a real production system. It runs services, serves applications, and responds to network requests. To an attacker scanning for vulnerable targets, the honeypot appears as a legitimate opportunity – sometimes a more attractive one than the real systems, because honeypots are deliberately configured with the kinds of weaknesses attackers seek.

The configuration varies by purpose. A honeypot designed to study credential-stuffing attacks might expose a fake authentication portal with weak password requirements. A honeypot designed to study malware behavior might emulate a vulnerable file server with default permissions. A honeypot designed to study reconnaissance patterns might respond to port scans with banners that suggest exploitable services.

Once an attacker engages, every action is logged. Login attempts, command sequences, files transferred, lateral movement attempts, command-and-control communications – all become artifacts that security researchers can analyze. The defender learns about attack tools, threat actor preferences, and emerging techniques. The attacker, meanwhile, has spent time on a target with no real value while leaving forensic evidence.

The defender benefits depend entirely on the honeypot’s isolation from production systems. A honeypot that connects to real infrastructure becomes a launching pad for the attackers it was meant to catch. The architectural discipline of keeping honeypots fully segmented from production resources is what determines whether the deployment helps the defender or hands the attacker an entry point.

Types of Honeypots

Different honeypots address different threats. The categories below are the most common ones deployed in 2026:

Production honeypots are deployed inside or alongside live networks. They serve as decoys that attackers might encounter while probing the real environment. Production honeypots prioritize ease of deployment and signal clarity – when something interacts with them, it’s almost certainly malicious because no legitimate business reason exists to access them.

Research honeypots are deployed in isolated environments specifically to study attacker behavior. Researchers configure them to maximize attacker engagement and capture detailed forensic data. These honeypots often run for months or years, building deep intelligence about specific threat actors or attack categories.

Email traps and spam traps place email addresses in locations only automated harvesters can find. Any mail received at these addresses is, by definition, unsolicited. The traps generate signal data about spam infrastructure, phishing campaigns, and address harvesting techniques.

Database honeypots present fake databases configured to look attractive to attackers. SQL injection attempts, privilege escalation efforts, and data exfiltration patterns become observable. The honeypot may respond with fabricated data designed to mislead the attacker about the environment they’ve compromised.

Malware honeypots invite malware infections by emulating vulnerable applications and APIs. The captured malware samples feed analysis pipelines that produce detection signatures, behavioral profiles, and threat intelligence reports.

Spider honeypots target web crawlers and automated reconnaissance tools. Pages and links visible only to crawlers – not to human users – capture data about which crawlers are scraping content, which are searching for vulnerabilities, and which represent legitimate search engines versus reconnaissance tools.

ICS/OT honeypots simulate industrial control systems, SCADA components, and critical infrastructure devices. These specialized honeypots have become more common as ICS-targeted threats have increased. They capture data about attacks specifically aimed at operational technology environments – a category where the cost of a missed attack is particularly severe.

Low-Interaction vs High-Interaction Honeypots

Honeypots also differ by how deeply they engage attackers:

Low-interaction honeypots simulate only the surface of a target system. They emulate basic TCP/IP services, respond to common probes, and capture initial reconnaissance data. They’re easy to deploy, light on resources, and produce quick signal. The trade-off: an attacker who engages briefly will leave, taking only the surface-level information that the honeypot can capture.

High-interaction honeypots present full operating system environments, real applications, and convincing depth. The attacker can move through the system as if it were a real compromise. The defender captures detailed information about post-compromise behavior – privilege escalation, lateral movement attempts, persistence techniques, command-and-control patterns. The trade-off: high-interaction honeypots are resource-intensive, complex to maintain, and create real risk if not properly isolated. A determined attacker who realizes they’re in a honeypot may attempt to use it as infrastructure for attacks against external targets.

The classification matters because the choice between low and high interaction determines what intelligence the deployment can produce. Low-interaction honeypots are useful for breadth – gathering data about many attackers across a wide attack surface. High-interaction honeypots are useful for depth – learning detailed tradecraft from specific actors.

What Is a Homelab Honeypot?

A homelab honeypot is a honeypot deployed in a personal or educational environment, typically by a security professional, student, or hobbyist learning about offensive and defensive techniques. The deployment is non-commercial and intended for learning rather than production threat intelligence.

Common homelab honeypot tools include Cowrie (an SSH/Telnet honeypot), T-Pot (a multi-honeypot platform from Deutsche Telekom that bundles many honeypot tools), Honeyd (a low-interaction honeypot framework), and Dionaea (focused on capturing malware samples). These tools are open-source, well-documented, and run on modest hardware – often a single Raspberry Pi or a small virtual machine.

Homelab honeypots serve several purposes for the operator. They develop hands-on understanding of attack techniques. They provide insight into the volume and variety of automated attacks against internet-facing infrastructure. They build skills in log analysis, intrusion forensics, and threat intelligence workflows. The data captured rarely produces actionable intelligence beyond what professional threat intelligence services already provide, but the educational value is significant.

For security professionals building skills, homelab honeypots represent a practical entry point into threat research. Many enterprise security careers begin with a homelab honeypot deployment that taught the operator how attackers actually behave – knowledge that would be hard to gain from documentation alone.

What Is a Honeypot Operation?

A honeypot operation is the structured deployment, monitoring, and analysis of one or more honeypots as part of a broader security or intelligence-gathering program. The operation includes the honeypot infrastructure itself, the analytical processes that consume captured data, and the operational discipline that turns raw observations into useful intelligence.

Government agencies, large enterprises, and threat intelligence vendors run honeypot operations at scale. The Honeynet Project, founded in 1999, established many of the conventions that modern honeypot operations follow. Commercial threat intelligence vendors operate honeypot networks spanning thousands of nodes across geographies. Academic institutions run honeypot operations focused on specific research questions.

The operational disciplines that distinguish a successful honeypot operation from a failed one include strict isolation from production infrastructure, careful management of any attacker activity that might propagate beyond the honeypot, regular legal review (because honeypot operations can intersect with computer fraud laws in unexpected ways), and disciplined data analysis that produces actionable findings rather than just log volume.

What Is a Honeypot Trap?

The phrase “honeypot trap” is often used interchangeably with “honeypot,” but it specifically emphasizes the deceptive function. The trap aspect is the lure – the deliberate appearance of vulnerability or value that draws an attacker’s attention. The honeypot is the system; the trap is the deception that makes the system effective.

In some uses, “honeypot trap” specifically refers to honeypots designed to capture attacker credentials, tools, or techniques rather than just observe behavior. The trap captures something specific that the defender wants to study or use. This usage overlaps with what some practitioners call a “honeytoken” – a specific decoy element (a fake credential, a fake document, a fake API key) embedded in real systems to detect unauthorized access.

The architectural distinction matters because honeypot traps deployed in production environments require careful planning. A fake credential left in a real configuration file may detect reconnaissance – but it also signals to attackers that the defender is watching, potentially driving them to more sophisticated techniques.

What Is a Honeypot in Cybersecurity?

In cybersecurity practice, a honeypot is a deliberately deployed decoy system that serves three primary functions: threat intelligence gathering, deception-based detection, and defense-in-depth contribution. The honeypot in cybersecurity is not a primary defense – it complements other security controls rather than replacing them.

The threat intelligence function captures data about attacker tools, techniques, and procedures (TTPs). Security teams use this data to refine detection rules, update threat feeds, and brief executive leadership on emerging threats specifically targeting their sector or technology stack.

The deception-based detection function exploits the false-positive properties of honeypot interaction. Because no legitimate business reason exists to interact with a honeypot, any interaction is suspicious. This produces high-confidence alerts compared to traditional intrusion detection systems, which often generate false positives from legitimate traffic that resembles attack patterns.

The defense-in-depth function distracts and delays attackers who reach the network. Time spent investigating a honeypot is time not spent attacking real assets. The data captured during the distraction informs incident response that may prevent broader compromise.

The honeypot in cybersecurity also has well-known limitations. It only sees activity directed at itself. A sophisticated attacker who fingerprints the honeypot may avoid it entirely, instead targeting real assets while the security team focuses on the decoy. The honeypot does not protect against attacks that don’t engage it. These limitations have driven the architectural shift documented in the next section.

What Is a Honeypot in Crypto?

The term “honeypot in crypto” refers to a specific category of cryptocurrency scam, distinct from the cybersecurity honeypot definition. A crypto honeypot is a smart contract or token deliberately designed to attract investors who can buy in but cannot sell out. The contract appears to function normally during initial trading – early buyers see prices rising, transactions completing, the token apparently legitimate. Then, when investors try to sell, the contract reveals hidden code that prevents the sale, traps the funds, or directs them to the attacker’s wallet.

Crypto honeypots are a fraud pattern, not a cybersecurity tool. They’re identified by smart contract analysis tools that examine the contract code for known honeypot patterns, by investigation of the developer’s other contracts and wallet behavior, and by monitoring of the token’s actual sell transactions versus marketed sell capability.

The cryptocurrency honeypot phenomenon overlaps with cybersecurity in one specific way: the same techniques that attackers use to identify cybersecurity honeypots (looking for telltale signs of deception) are sometimes used by sophisticated crypto investors to detect honeypot contracts before investing. The pattern recognition transfers across domains even though the underlying systems differ completely.

For the rest of this article, “honeypot” refers to the cybersecurity definition, not the crypto fraud category.

The Limits of Honeypots in Modern Environments

The honeypot concept assumes a network architecture that has become less common since 2020. In the traditional model, a perimeter separates “inside” (trusted) from “outside” (untrusted). Honeypots sit somewhere in the architecture – at the perimeter, in the DMZ, inside the network – and observe traffic that crosses into their visibility. The model works because the perimeter creates structure: there’s an inside to defend, an outside to monitor, and a clear question of what crosses between them.

Modern environments don’t fit this model cleanly. Cloud workloads run outside the perimeter. Remote workers connect from anywhere. SaaS applications operate without any traditional network boundary. Industrial control systems integrate with cloud analytics. The “inside vs outside” question becomes a “trusted vs untrusted” question that depends on context – and context isn’t a fixed property of network location.

The architectural shift this drove is the move from perimeter-based access to identity-based access, where every connection is treated as untrusted regardless of network position. Authentication happens per-session. Authorization happens per-operation. The “inside” that honeypots traditionally guarded – the assumption that an attacker reaching the network is contained until detected – is replaced by the assumption that every connection requires explicit verification.

In this architectural shift, several traditional honeypot assumptions stop applying:

Assumption 1: The attacker has crossed an outer perimeter. Modern Zero Trust architectures don’t have a single outer perimeter. There are many access decisions, each evaluated independently. An attacker with stolen credentials doesn’t “get past the perimeter” – they pass one access decision and face another, then another. The honeypot model assumes a discrete crossing event that may not exist.

Assumption 2: The attacker, once inside, has lateral movement potential. ZTNA architectures specifically eliminate lateral reachability. A user authorized for one application has no network path to another application – even if both run on the same physical host. The honeypot’s role of catching lateral movement loses much of its function when lateral movement is structurally constrained.

Assumption 3: The attacker reaches network targets through reconnaissance. Reverse Access architectures eliminate the reconnaissance surface that reconnaissance tools probe. There’s no listener responding to scans. There’s no service banner suggesting exploitable software. There’s nothing to find. The honeypot’s role of capturing reconnaissance traffic depends on reconnaissance being possible – which Reverse Access architectures structurally prevent.

The pattern: honeypots address the threats that legacy architectures created the conditions for. As architectures change, the threats change, and the honeypot’s relevance shifts.

Why Modern Zero Trust Architectures Reshape the Honeypot Question

The shift from perimeter-based to Zero Trust architectures changes when and why honeypots get deployed. The change is not “honeypots are obsolete” – it’s “honeypots fit a different role than they did in 2010.”

In a perimeter-based architecture, honeypots are often a primary detection mechanism. The defender assumes attackers will try to cross the perimeter and uses honeypots to catch the ones that do. The honeypot is positioned as the canary that warns when something has gone wrong with the primary defenses.

In a Zero Trust architecture, the primary defense is structural rather than detective. The fundamental architectural difference between Zero Trust Network Access and traditional VPN-based remote access is that ZTNA eliminates the categories of attack that traditional architectures relied on detection to catch. There’s no “attacker who got past the perimeter” because there’s no perimeter to get past. There’s no “lateral movement to detect” because lateral movement is structurally prevented. There’s no “service exposure to monitor” because the services aren’t exposed.

The honeypot in this environment serves different purposes:

Threat intelligence remains valuable. Even in well-architected Zero Trust environments, understanding what attackers are doing in the broader threat landscape informs policy decisions. Honeypots run by threat intelligence teams continue to capture data that helps defenders calibrate their approach.

Research environments still benefit. Security researchers studying specific attack categories still deploy honeypots as part of their research methodology. The honeypot’s value as a research tool doesn’t depend on its primary defense role.

Defense-in-depth still matters. Even with strong primary architecture, layered defenses provide redundancy. A honeypot deployment in a Zero Trust environment may catch attackers who somehow bypass the primary architectural controls. The honeypot is no longer the first line of defense, but it can still be a useful late line.

What changes is the resource allocation. Organizations that previously invested heavily in honeypot infrastructure as primary detection often shift those resources toward architectural prevention as Zero Trust matures. The honeypots that remain serve narrower, more specific purposes than they did when they were the primary detection mechanism.

How Reverse Access Architecture Changes What Honeypots Need to Watch

The most architecturally significant shift is the elimination of the inbound listener. In traditional architectures, every internet-facing service must have a listener – a service binding to a port that accepts incoming connections. Listeners are the primary attack surface that scanners probe, that vulnerabilities target, and that honeypots monitor for unusual interaction.

Reverse Access architectures invert the connection direction. Internal components establish outbound connections to external gateways. The gateways broker authorized traffic back to the internal components. From an external perspective, the protected network has no listening services. There’s no port scanning surface. There’s no exposed banner. There’s nothing to attack.

This architectural property – eliminating the inbound listener that traditional architectures depend on – changes what defenders need to monitor. The traditional concern of “is anyone scanning our exposed services” becomes moot when there are no exposed services. The honeypot’s role of capturing reconnaissance traffic loses much of its applicability when reconnaissance is structurally prevented.

The honeypots that remain useful in Reverse Access environments are typically deployed elsewhere in the architecture – at gateway endpoints (where external connections terminate), at identity provider integration points (where credential abuse might be observable), or as research tools studying broader internet threat patterns rather than threats specific to the protected network.

Honeypots and Microsegmentation: How Architecture Constrains the Need for Detection

Microsegmentation provides another architectural property that changes when honeypots are needed. In traditional flat networks, an attacker who reaches one system has potential paths to many others. Honeypots embedded in such networks have a clear role: catch the attacker during the lateral movement phase.

In microsegmented networks, lateral movement is structurally constrained. Each workload, application, or system communicates only with its specifically authorized peers. An attacker reaching one system has no automatic path to others – they would need to compromise additional access decisions, each evaluated independently.

The architectural pattern of identity-based microsegmentation that closes every door an attacker might use for lateral movement reduces the operational space where honeypots traditionally operated. The “honeypot waiting in the path of an attacker’s lateral movement” deployment pattern depends on lateral movement being possible. When microsegmentation eliminates that movement at the architectural level, the honeypot’s role shifts toward narrower, more specific use cases.

Microsegmentation doesn’t eliminate the value of honeypots – but it changes where they fit. Honeypots become more like specialized research instruments than primary defensive infrastructure.

Sector-Specific Considerations: Government, Defense, and Homeland Security

The honeypot conversation differs significantly by sector. Government, defense, and homeland security environments operate under specific constraints that shape both how honeypots are deployed and how Zero Trust architectures are replacing the need for them.

Government honeypots. Federal, state, and local government agencies have historically operated honeypot programs as part of broader threat intelligence efforts. These programs continue but increasingly operate within Zero Trust frameworks driven by OMB M-22-09, the CISA Zero Trust Maturity Model, and agency-specific Zero Trust strategies. The honeypot remains useful for threat intelligence, but the agencies are reducing their reliance on honeypots as primary detection. Federal and state agencies migrating to Zero Trust architectures for government systems increasingly treat honeypots as research tools rather than primary defensive infrastructure.

Defense honeypots. Defense agencies operate honeypots in deeply specialized configurations – often in classified networks where the threat intelligence value is particularly high. The DoD Zero Trust Strategy with its FY2027 Target capabilities is reshaping how these honeypots fit into broader architectures. Multi-classification environments now rely on Zero Trust deployment patterns built for state, federal, and defense agencies, where honeypots play different roles than in commercial deployments because the threat landscape differs and the detection requirements operate under stricter classification constraints.

Homeland security honeypots. Homeland security operations – fusion centers, joint task forces, critical infrastructure protection – have historically deployed honeypots as part of the broader CISA-coordinated threat awareness program. The integration of these operations with Zero Trust architectures designed for homeland security systems is changing how the honeypot data flows into operational decision-making and how the underlying architectures are evolving toward prevention-first models.

Across all three sectors, the pattern is consistent: honeypots remain part of the threat intelligence toolkit, but they’re no longer the primary detection mechanism they were in 2010-2018. The shift is driven by architectural change, not by any decline in honeypot quality.

The TerraZone truePass Architectural Approach

For organizations evaluating the architectural shift that’s reshaping the honeypot question, the TerraZone truePass platform demonstrates the pattern in deployable form. The platform combines Reverse Access (eliminating inbound listeners), identity-aware proxy enforcement (replacing network-level access with application-level access), and continuous verification (replacing once-per-session authentication with per-operation evaluation).

The architectural effect on the honeypot question: the conditions that made honeypots central to detection in legacy environments largely don’t exist in truePass-deployed environments. There are no exposed listeners for scanners to find. There’s no lateral movement potential for embedded honeypots to catch. There’s no perimeter for honeypots to guard. The architectural prevention reduces – but doesn’t eliminate – the role honeypots play.

The same architectural pattern is what TerraZone’s Zero Trust Access service implements across enterprise, government, and OT deployments – Reverse Access foundation, identity-aware proxy enforcement, and continuous verification combined in a single product rather than assembled from separate point solutions.

When Should You Still Deploy Honeypots?

Even in well-architected Zero Trust environments, honeypots retain value for specific purposes:

Threat intelligence operations. If your security team produces threat intelligence as a deliverable – for executive briefings, sector ISACs, or intelligence partnerships – honeypots remain a useful collection mechanism. The data flows into intelligence products, not into primary detection.

Research and education. Security researchers, academics, and security training programs continue to use honeypots as research tools. The educational value of honeypot deployment for skill development is well-documented.

Defense-in-depth deployments. Organizations with mature Zero Trust architectures sometimes deploy honeypots as the last layer in a defense-in-depth strategy. The reasoning: even excellent primary architecture might fail in unforeseen ways, and the honeypot provides one more chance to catch what slipped through.

Specific threat actor research. When an organization knows it’s targeted by a specific threat actor (nation-state, criminal group, or specific APT), customized honeypots may be deployed to study that actor’s tradecraft. This use case is closer to research than to general detection.

What you probably shouldn’t do is deploy honeypots as your primary detection mechanism in a 2026 architecture. The architectural patterns that make honeypots work as primary detection are increasingly absent from modern environments.

Frequently Asked Questions

What is a honeypot in cybersecurity?

A honeypot in cybersecurity is a deliberately deployed decoy system designed to attract attackers, gather threat intelligence, and provide deception-based detection. The honeypot looks like a legitimate target – running services, hosting data, responding to probes – but contains no real business value. Every interaction is recorded and analyzed. Honeypots serve as complementary security tools rather than primary defenses, and their role has shifted significantly as Zero Trust architectures have replaced perimeter-based security models.

What is a honeypot trap?

A honeypot trap is a honeypot configured to capture specific attacker artifacts – credentials, tools, or techniques – rather than just observe behavior. The trap aspect emphasizes the deceptive function: the deliberate appearance of vulnerability that draws attackers into engagement. In some uses, “honeypot trap” overlaps with “honeytoken” – a specific decoy element (fake credential, fake document, fake API key) embedded in real systems.

What is a homelab honeypot?

A homelab honeypot is a personal or educational deployment, typically run by security professionals, students, or hobbyists for learning purposes. Common tools include Cowrie, T-Pot, Honeyd, and Dionaea. Homelab honeypots run on modest hardware (often a Raspberry Pi or small VM) and serve to develop hands-on understanding of attack techniques, log analysis, and threat intelligence workflows. The educational value is significant; the operational threat intelligence value is typically modest.

What is a honeypot operation?

A honeypot operation is the structured deployment, monitoring, and analysis of honeypots as part of a broader security or intelligence-gathering program. The operation includes the honeypot infrastructure, the analytical processes that consume captured data, and the operational discipline that ensures the deployment serves its purpose without creating new risks. Government agencies, large enterprises, and threat intelligence vendors run honeypot operations at scale.

What is a honeypot in crypto?

A honeypot in cryptocurrency refers to a fraud pattern where a smart contract or token is designed so investors can buy in but cannot sell out. Hidden code in the contract prevents sales, traps funds, or redirects them to the attacker. This is distinct from the cybersecurity honeypot definition – the crypto honeypot is a fraud category, not a defensive tool. Smart contract analysis tools can identify many crypto honeypot patterns before investors fall victim.

Are honeypots still useful in 2026?

Yes, but in different roles than in 2010-2018. Honeypots remain valuable for threat intelligence operations, research and education, defense-in-depth deployments, and specific threat actor study. They’re typically not primary detection mechanisms in well-architected Zero Trust environments because the architectural patterns (no inbound listeners, no lateral reachability, identity-attributed access) eliminate the conditions honeypots were designed to monitor. Organizations adopting Zero Trust often shift resources from honeypot infrastructure toward architectural prevention.

Can honeypots replace ZTNA?

No. Honeypots and ZTNA address fundamentally different security functions. Honeypots provide threat intelligence and deception-based detection – they observe attackers. ZTNA provides architectural prevention – it constrains what attackers can do regardless of whether they’re observed. The two can complement each other in defense-in-depth deployments, but they don’t replace each other. Organizations using honeypots as a substitute for ZTNA-style architectural controls typically discover the limitation when sophisticated attackers fingerprint the honeypots and target the actual production systems.

Do honeypots work against insider threats?

Honeypots have a specific role in insider threat programs. The high-confidence signal property – any honeypot interaction is suspicious because no legitimate business reason exists – applies equally to internal and external attackers. A negligent insider who explores systems beyond their work assignment may interact with honeypots, generating signal that policy-only programs miss. However, malicious insiders with specific knowledge of the environment often avoid honeypots they recognize. The honeypot’s value against insider threats is real but bounded – and architectural controls (identity-attributed audit, application-level access, microsegmentation) typically address insider threats more comprehensively than honeypots can.

Conclusion

A honeypot is a decoy system designed to attract attackers, gather intelligence, and contribute to defense-in-depth security programs. The concept has been valuable since the late 1990s and continues to serve specific purposes in modern security operations. What has changed is the architectural context in which honeypots operate.

Traditional perimeter-based architectures created conditions that made honeypots central to detection. Attackers had to cross perimeters; honeypots watched for them. Attackers moved laterally once inside; honeypots caught them in the act. Attackers conducted reconnaissance against exposed services; honeypots captured the reconnaissance. The honeypot’s role made sense because the architecture made the threats predictable.

Modern Zero Trust architectures eliminate many of those conditions. Reverse Access architectures eliminate inbound listeners. Identity-based access eliminates lateral reachability. Per-session, per-operation policy enforcement eliminates the post-authentication trust that traditional architectures relied on detection to bound. The threats that honeypots were designed to catch increasingly don’t have a place to operate.

This doesn’t make honeypots obsolete. It redefines their role. Threat intelligence, research, education, and defense-in-depth all remain valid purposes. What’s no longer recommended is deploying honeypots as primary detection in an architecture that has eliminated the conditions for the threats honeypots watch for.

The architectural shift is the substantive answer to “what is a honeypot in cybersecurity in 2026.” The honeypot is a tool. The architecture determines whether the tool is needed for primary defense or for narrower research and intelligence purposes. Organizations evaluating their security architecture should make that determination explicitly rather than continuing legacy honeypot deployments by inertia.