What is a honeypot and should your security team run one?

A honeypot is a decoy system or resource that is designed to attract attackers, and has no real business function, so any activity directed at it is suspicious. It gives defenders early, low-noise warning and data on attacker methods. It also takes skill to run and carries legal and operational risk.

How do standards define it?

The NIST glossary, citing CNSSI 4009 and IETF RFC 4949, defines a honeypot as a system, such as a web server, or a system resource, such as a file on a server, designed to be attractive to potential crackers and intruders, like honey is attractive to bears.

NIST SP 800-94, the guide to intrusion detection and prevention systems, adds the operating logic. Honeypots are hosts that have no authorized users other than their administrators because they serve no business function, so all activity directed at them is considered suspicious. Attackers will scan and attack them, giving administrators data on new trends and attack tools, particularly malware.

That logic is the value. Your real systems produce huge volumes of normal traffic that hide the bad. A decoy produces almost none, so a single connection stands out.

What do honeypots give you?

• Early detection of scanning or lateral movement inside a network.
• Low false positives, because legitimate users have no reason to touch the decoy.
• Samples of tools and techniques used against you, collected without risk to production data.

What are the cautions?

SP 800-94 is clear that honeypots are a supplement to, not a replacement for, other security controls such as intrusion detection and prevention. It says that if you use them, qualified incident handlers and intrusion detection analysts should manage them. It also states that the legality of honeypots has not been clearly established, so organizations should carefully study the legal ramifications before planning any deployment. Take that last point seriously and ask counsel before you deploy anything that interacts with outside parties.

Practical risks follow from this. A badly isolated honeypot can become a stepping stone into your real network. A neglected one can be taken over and used to attack others from your address. And it produces alerts that someone must be ready to handle.

What kinds are there?

Think of a range from simple to demanding:

1. Decoy files and credentials. A document named like a password list, or a fake access key in a repository, that alerts when used. No system to maintain.
2. Low-interaction decoys. A service that looks like a database or file share but only records connection attempts.
3. High-interaction systems. A real operating system, fully instrumented, that lets an attacker act. This gives the richest data and carries the most risk.

A constructed example: a company with a small security team does not want to run decoy servers. It plants a fake cloud access key in a private code repository and sets an alert on any use of that key. Three months later the alert fires from an unfamiliar address. A former contractor's laptop had a cloned copy of the repository. The team did not need a decoy server at all, and the signal had no false positives.

How to check or apply this

1. State the question you want answered: do we want to detect internal movement, collect threat data, or catch stolen credentials?
2. For internal detection, start with decoy credentials and files. They need no new servers.
3. If you run a decoy system, put it on its own network segment with no route to production data and strict egress rules.
4. Decide in advance who gets the alert and what they do when it fires, and test that path.
5. Ask legal counsel to review the plan, especially for decoys reachable from the internet.
6. Review after 90 days: how many real events, how many noise events, how much staff time.

Quick check

Sources

• NIST CSRC Glossary, honeypot
• NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS)

Last reviewed: 18 October 2026.