SC-26 Decoys asks you to include components in your systems that are designed specifically to be the target of malicious attacks, for detecting, deflecting and analyzing those attacks.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from.
The guidance calls them honeypots, honeynets or deception nets. They attract adversaries and deflect attacks away from operational systems. It adds two cautions. Decoys need supporting isolation so deflected malicious code does not infect your real systems, and depending on use, you may need to consult legal counsel before deployment. SC-26.1 covers detection of malicious code.
What it means in practice
A decoy can be small. A fake file server that no one should touch, a canary token inside a document, or a dummy database credential that alerts when used. Because no legitimate user has a reason to touch them, any activity is a strong signal.
Decoys fit small teams better than people expect. A single canary credential in a repository, an AWS style access key that is never used legitimately, will tell you within minutes if someone has copied your source or your secrets. A fake internal wiki page titled something attractive does the same job for lateral movement.
The evidence needs to show more than existence. Auditors want to see that decoys are monitored and that someone acts. Keep the alert history, even if it shows nothing but your own test triggers. Record the date, the trigger, who responded and how long it took. That turns a gimmick into a control.
Isolation is the line between a useful decoy and a new weak spot. A honeypot server that shares credentials, network routes or trust relationships with production can become the way in. Review it like any other asset, patch it, and put it in a segment with no path to real data.
Legal review is worth a short note in your records. If a decoy captures commands, files or addresses from outside parties, counsel may want to confirm the collection fits your terms and local law. The guidance explicitly mentions consultation with legal counsel for some deployments.
Evidence to collect
- The list of decoys, where they sit and what they imitate.
- Isolation design, including network rules.
- Alert rules and a sample alert.
- A record of legal review or approval.
- An incident or tabletop record showing a decoy hit was handled.
Common gaps
A decoy with a route into production. Alerts that go to a mailbox nobody reads. Decoys that look obviously fake. No legal check where the decoy collects data about outsiders.
How to implement it
Start with canary tokens because they cost almost nothing. Place a few credentials and documents in locations an intruder would browse. Wire the alerts to your on call channel. For network decoys, place them in an isolated segment and log everything.
Then rehearse. Trigger a canary on purpose and confirm the response matches your runbook.
Try it yourself
If a decoy fires, you are in an incident. This walkthrough shows how the response and review fit together.
Click through it at your own pace, or open it full screen.
Quick check
Do decoys need isolation?
Yes. The guidance says supporting isolation measures are needed so deflected malicious code does not infect operational systems.
Are canary tokens decoys?
They are a lightweight form. They are designed to be touched only by an attacker and alert when they are.
