Your honey account fires every Tuesday at 02:00 from the credentialed vulnerability scanner — what do you change?

## Read the situation correctly first A recurring fire at the same hour, from the same source, matching a schedule you own, is a benign interaction with the bait rather than a broken detection. The decoy did exactly what it was built to do: something authenticated as an account nothing should authenticate as. The defect is upstream — legitimate machinery can reach an object whose entire value was being unreachable by legitimate machinery. Before acting, confirm two things cheaply: that the recurrence really matches a schedule your organisation runs, and that the identity doing it is the scanner's own service identity rather than something wearing its window. A weekly pattern that matches a change calendar you own is very different from a weekly pattern nobody can point to an owner for. ## Why the obvious fix is the wrong one The reflex is to add a suppression: ignore fires where the source host is the scanner, or where the account is the scanner's service identity. Three problems follow. **It hands an adversary a specification.** An exclusion is a documented set of conditions under which your highest-fidelity detection stays silent. Anyone who can read your detection content, or who simply guesses that the scanner is excluded, has a window and a host to operate from. Deception's value is that it needs no exception; the first exception is disproportionately expensive. **It degrades the signal permanently.** Bait's precision was structural. Once the rule carries a condition, its precision depends on that condition being correct, which means it now needs review like any tuned detection. **It leaves the underlying leak in place.** The scanner reaching the decoy usually means the decoy leaked into some inventory — an asset list, a scan target group, a vault, a governance tool's population. If that leak is not closed, the next tool that consumes the same list will also reach the bait, and you will write a second exclusion. ## Fix the placement The decoy should be discoverable by enumeration and by nothing else. Concretely: - remove the decoy from the scanner's credentialed target list, or exclude the organisational unit the decoys live in from its authenticated scope; - remove the decoy from whatever inventory fed it there — the asset database, the account population an identity-governance tool sweeps, a monitoring check; - confirm the decoy's credential is not stored in the password vault, which is a common way a decoy joins the population of "accounts we test"; - if the scanner must sweep the entire directory by policy, move the bait to a place its authenticated path does not go, rather than arguing the scanner should change. After the change, expect silence and verify it: a decoy that has stopped firing after a placement fix should be re-checked deliberately, because you cannot tell a fixed decoy from a deleted one by looking at its output. ## When you cannot fix the placement Sometimes the compliance scanner genuinely must authenticate everywhere. Then make the exclusion as narrow and as noisy as possible. Pin the whole tuple: the scanner's service identity, its source host, the action it performs, and the expected window. Alert on any deviation — same identity from a different host, same host outside the window, the identity performing something other than what the scanner does. That converts a hole into a second, narrower tripwire, and it means the exclusion still produces a signal when someone tries to hide inside it. Give the exclusion an expiry and an owner, so it is revisited rather than inherited. ## The administrator variant The same class of problem arrives from a different direction: an administrator sees an account with no recent logon, decides it is stale, and deletes or disables it. Your hygiene programme is doing its job, and it has just removed your tripwire. That is a placement problem too — the decoy was designed to look dormant and your cleanup policy selects for dormancy. The fixes are structural rather than social: directory-level protection against deletion or modification of the decoy objects, an alert on changes to the decoy container so a tidy-up produces a ticket instead of a silent hole, and attribute choices that keep the object outside the cleanup policy's selection criteria. ## Record the decision Whichever route you take, write down why, because the next person to see the change — an analyst wondering why the scanner is excluded, or an administrator wondering why an unused account cannot be deleted — will otherwise undo it. Where that record lives matters: not in the systems an intruder enumerates first. ## What a strong answer sounds like "That is the bait working and the placement failing. I would take the decoy out of the scanner's credentialed scope and out of whatever inventory put it there, rather than excluding the scanner in the rule — an exclusion is a shape someone can operate inside, and it costs me the one detection that needed no tuning. If policy forces the scanner to reach everything, I pin identity, host, action and window and alert on any deviation, with an owner and an expiry on the carve-out."