What is a honeypot in cybersecurity?

Direct Answer

A honeypot is a decoy system deliberately set up to look like a real server, workstation, or service, with no purpose other than to be found and attacked. It holds no real data and serves no real users, so there's no legitimate reason for anyone to touch it. That's what makes the resulting signal reliable: an interaction with a honeypot isn't a pattern that might turn out to be a false alarm, it's unauthorized activity by definition. Tracebit builds on the same principle with lighter-weight canary resources rather than full decoy servers — fake credentials and cloud assets that caught two separate red team engagements against Riot Games, the video game company behind League of Legends and Valorant, the more recent one within minutes of the test starting.

How a honeypot actually works

The mechanics are simple even when the deployment isn't. A honeypot gets built to resemble something worth attacking — a poorly patched web server, an exposed database, a workstation with saved credentials — and then it sits there, doing nothing, until someone interacts with it. Because real employees and real customers have no reason to go near it, any connection attempt, login, or file access gets logged as what it almost certainly is: reconnaissance or an active attack.

That's a genuinely different kind of signal than most security tooling produces. A firewall rule or an anomaly detector has to guess whether a given action is malicious, based on patterns that could, in principle, also happen for an innocent reason. A honeypot skips that guesswork entirely. There's no benign scenario where someone stumbles onto a server that was never announced, never linked, and never used for anything real.

Types of honeypots

Low-interaction honeypots simulate just enough of a service to look convincing — an open port that responds like SSH or RDP without actually running a full operating system behind it. They're cheap to deploy and low-risk, since there's no real system underneath for an attacker to compromise, but they also don't hold an attacker's attention for long. Tracebit's canary resources sit at this lighter end of the spectrum, without even the compute a low-interaction honeypot still runs.

High-interaction honeypots run real, or close to real, operating systems and services, giving an attacker something they can actually work with: log in, poke around, try to escalate. That depth is useful for studying attacker behavior, but it comes with real operational cost — patching, isolation, and monitoring the honeypot itself becomes its own ongoing job.

Production honeypots sit inside a live environment specifically to catch intrusions early. Research honeypots exist mainly to study attacker tools and techniques rather than to protect anything in particular.

The cost problem that shaped the field's direction

A recurring complaint from security practitioners about classic, full-decoy honeypots is the operational burden: standing up an appliance or virtual machine in every network segment, then maintaining both the decoy and the honeypot software running it, on top of everything else already on a team's plate. One widely echoed account on a security forum described exactly this — after deploying a commercial honeypot platform across a large environment, the ongoing maintenance outweighed what the tool ever caught, and the team abandoned it in favor of turning existing servers and workstations into better sensors instead.

That complaint is really about deployment weight, not about whether the underlying idea works. The industry's response has largely been to make the decoy lighter. Instead of a full fake server that needs patching and isolation, a canary resource can be a single fake credential, an empty cloud storage bucket, or a decoy identity, something with no compute behind it to maintain, deployed as regular infrastructure-as-code rather than a separate appliance. The security team at Coveo, an AI-powered enterprise search and relevance platform, deployed dozens of these lightweight decoys across their cloud environment from a seven-line Terraform module — a different order of effort entirely from racking a dedicated honeypot appliance per network.

Conclusion

A honeypot's core idea, something fake that has no reason to be touched, is one of the more reliable signals in security precisely because it removes the guesswork other detection has to do. The idea hasn't changed. Fewer teams now stand up full decoy servers that need their own maintenance; more deploy lightweight fake credentials and cloud resources that catch the same kind of unauthorized access without the operational weight that made classic honeypots a hard sell for most organizations.

Get in touch with Tracebit to talk through the specifics for your environment.

FAQ

Do security teams realistically have time to monitor a honeypot?

Not if it means checking a separate dashboard by hand. A honeypot only earns its keep if alerts route into whatever the team already watches — a SIEM, Slack, PagerDuty — the same way any other detection source would. Left in a console nobody opens, it's no better than not having one.

Isn't running a honeypot in the cloud risky — what if it gets exploited and racks up a bill?

A traditional honeypot that spins up a real, reachable service carries that risk, and it's a concern raised often by teams who've had cloud ingress or egress costs get away from them. A canary resource — a fake credential, or an empty decoy bucket with no compute behind it — sidesteps the problem, since there's nothing running that could actually be abused.

Is a honeypot worth deploying if my company isn't a high-value target?

The value isn't really about target size, it's about the alert being unambiguous. Any company can place a fake credential or fake file where a real one would sit; the moment it's touched, that's compromise, not inference. Cost has historically been the bigger barrier — classic honeypots requiring dedicated appliances weren't worth it for most teams, which is a different question from whether the underlying idea holds up.

What's the difference between a honeypot and a canary token?

A honeypot is usually a full decoy system — a fake server or service an attacker can actually log into and explore. A canary token is a single fake artifact — a credential, a document, a URL — that alerts the moment it's used, with nothing further to interact with. Tokens are far cheaper to deploy at scale; honeypots give an attacker more rope before they're caught.

Can attackers tell when something is a honeypot?

Experienced ones increasingly try. A honeypot with mismatched software versions, no real traffic history, or infrastructure that doesn't match the rest of the environment is exactly what a careful attacker learns to spot and avoid. That's part of why the field has moved toward lighter, more numerous fake artifacts blended into real infrastructure rather than a small number of obviously separate systems.