Unusual compared to what?
The pitch never varies: the system finds unusual behaviour. The question that decides whether it works is rarely asked out loud.
Measured against a company-wide average, almost everybody is unusual. Average together the executive who signs in from four countries a month, the engineer who chooses to work at three in the morning, and the clerk who touches one system all day, and the normal you get describes none of them. Alert on distance from that average and two things happen at once: the team drowns, and the session that actually matters sits comfortably in a middle that means nothing.
The useful comparison is smaller. Not this sign-in is unusual for the organisation but this sign-in is unusual for this account — the fixed-desk clerk suddenly arriving from abroad, the account whose source addresses have gone from two to forty in an afternoon.
The only normal worth measuring against belongs to a single account.
One baseline per account, learned and kept moving
Mirket ITDR builds a picture of each account from the authentication events it produces signing in through MFA, SSO and self-service. A clustering model groups what that account ordinarily does, and a new sign-in is measured by how far it sits from those groups.
This is machine learning doing the part it is genuinely good at. Nobody writes the rule for what normal looks like for a particular person, because nobody could — the model derives it, per identity, from how that identity has actually behaved. Risk scoring is model-driven for the same reason, and it sharpens as it sees more. Attacks that a counter would miss are read the same way: password spraying and credential sharing are analysed by model rather than measured against a fixed number, because an attacker who stays under the threshold is precisely the one worth catching.
Two properties matter more than the algorithm itself. The unit is the individual, so a deviation is a deviation for them. And the picture updates, so somebody who changes role, starts travelling or adopts a new working pattern moves their own baseline with them rather than becoming a permanent source of noise. A threshold written at go-live is wrong within a quarter and gets switched off; that is how most behavioural detection actually dies.
The signals it actually reads
Worth being concrete, because “behavioural analytics” is a phrase that can mean almost anything.
- Where it comes from, and how many wheres An account that has always authenticated from two or three addresses suddenly using many is a shape worth reading — whether that is a proxy pool, a botnet, or a credential in more hands than one.
- How far, and how fast Distance between consecutive sign-ins measured against the time between them. Two locations nobody could have travelled between is a strong signal — and a VPN exit point makes the same shape, which is why it is weighed rather than obeyed.
- How the account fails The ratio of second-factor failures to successes, against what is ordinary for this person. Everybody fumbles a code occasionally; a sustained change in that ratio is not everybody.
- When it turns up, and how that goes An account that has never signed in before six in the morning doing exactly that, and fumbling the second factor when it does. Either half alone is nothing. Together they are a shape.
None of these raises an alarm alone. The reason to combine them is that each one on its own is mostly innocent — the combination is where the signal lives, and combining is the part that is actually difficult.
And one signal that isn’t behaviour at all
A second factor is worth whatever the device holding it is worth. A registered phone that has since been rooted or jailbroken is not the device that was enrolled — its protections have been deliberately removed, and an approval coming from it carries less weight than the same approval did last year.
Mirket reads the security state of the enrolled device, which makes this the rare signal that needs no history and no comparison. It isn’t a claim that the user is hostile. It is a claim that one half of their authentication has quietly become weaker than it was, and that the risk picture should say so.
Your data builds your baseline, and nobody else’s
This is the first question any data protection officer asks about a detection service delivered from a vendor’s cloud, so it deserves a direct answer rather than a footnote.
Each account is scored against its own history, within your own tenant. The comparison is never with another organisation’s users, and your authentication activity is not assembled into a model that serves anybody else. What improves centrally is the engine — the detection logic, the threat intelligence, the techniques it recognises — which is a different thing from a model built out of your traffic.
The platform is also deployed regionally, so a tenant’s data stays in the region it was provisioned in. What is sent, where it is held and for how long is set out in the data processing documentation rather than summarised on a marketing page.
The detection that needs no baseline at all
Everything above compares an account with its own past. That is the right approach, and it has a price: it needs a past to compare with. An account used once a month builds a shape slowly, and a model always leaves a margin where both false alarms and missed attacks live.
Deception removes the comparison entirely.
Plant an account that looks like a domain administrator, or a credential that looks like it belongs to a service account, somewhere an intruder will find it. Then never use it. No process authenticates with it. No person knows it. It has no job at all — so when it turns up, there is nothing to weigh against it.
Everything else asks whether behaviour looks normal. A decoy has no normal, so contact is the answer.
- Decoy accounts Accounts built to resemble the privileged ones an intruder hunts for, sitting among the real ones and matching how you actually name things. Nobody signs in as them, ever.
- Decoy credentials Passwords that look like they were left in a configuration file or a script, and belong to nothing. Using one means having collected it from where it was planted.
- Decoy enrolment pages Registration pages that look like the real way to add a device to an account, and lead nowhere. Somebody working through one has gone looking for the way to become a second factor.
- Decoy applications Applications that appear to be available and have no users at all. Nothing real ever opens them, so reaching for one is somebody taking an inventory of what is here.
Three things have to be true for any of them to work: it has to resemble what an attacker is actually hunting, which means matching your real naming conventions; it has to sit where they look rather than off in a corner; and nothing legitimate can ever touch it — no process, no integration, no monitoring script.
The last two are worth noticing for what they cover. A decoy credential catches somebody who has already collected something. A decoy enrolment page and a decoy application catch somebody still looking — which is earlier, and quieter, and the stage almost nothing else has purchase on.
Why a decoy scores higher than anything else
Every other detection holds an innocent explanation against a hostile one. A failed second factor might be a flat battery. An impossible journey might be a VPN egress point. A burst of failures might be a misconfigured client. The detection’s job is to decide which, and a well-built one says how sure it is.
A decoy has no innocent explanation available to it. That is why it carries the highest certainty score Mirket assigns — not because detection can ever be perfect, but because there is no competing story to weigh it against.
This is also why not every detection here is a model. A decoy has no behaviour to learn from and nothing to predict, so putting a model in front of it would add uncertainty rather than remove it. Knowing which detections should be learned and which should be exact is the part that makes the learned ones worth trusting.
It also tells you something the timestamp doesn’t. A credential planted to be found and later submitted means the finding already happened, so the intruder has usually been present longer than the alert implies.
And the two feed each other: a decoy hit is one of the inputs the behavioural model reads, so everything that account does afterwards is measured against a confirmed contact rather than from scratch.
Where the model runs out
Two limits worth knowing before a proof of concept rather than during one.
A baseline needs a past. An account that authenticates several times a day acquires a shape quickly; one used monthly takes far longer, and a brand-new account has nothing at all to be compared against. That is not a flaw to be tuned away — it is what a learned model is. It is also the reason a decoy sits on the same page: bait needs no history, so it covers exactly the accounts and the moments the model is weakest on.
The engine reads authentication. It sees an identity being used and how that use goes, not what happens inside an application afterwards. Account Takeover & Compromised Credential Detection sets out what that boundary does and doesn’t include, including how far privilege escalation and lateral movement are visible from the authentication layer.
Mapped to a framework, not asserted
Each detection is tied to the MITRE ATT&CK technique it represents. The practical value is not the diagram; it is that coverage becomes something you can report and argue about with evidence — which techniques are covered at the identity layer, which are not, and where the gap is somebody else’s product rather than a missing feature.
From a score to something happening
Every detection carries two numbers: how serious it would be if correct, and how confident the platform is. They are kept apart deliberately, because one threshold cannot serve both questions — Adaptive Authentication sets out how the pair chooses.
What follows lands on that account alone: shutting it out, retiring its password, or making the next attempt harder. Account Takeover Detection covers those three in detail. A model that only fills a dashboard is a reporting tool; the case for a detection layer rests on it acting while the thing it noticed is still going on.
Where this runs
Both sit inside Mirket ITDR, available as a service only. The model learns from the sign-in history the workforce modules accumulate, and a decoy is inert until somebody authenticates with it — so both apply wherever those modules are run that way. No collector, no forwarding, no mapping. Deployment covers the on-premise alternative and what it leaves out.
What changes with Mirket
| Before | With Mirket |
|---|---|
| Normal is a company-wide average | Normal is modelled for each account individually |
| One signal fires at a time, and most are innocent | Origin spread, velocity, failure ratio and rhythm are weighed together |
| A threshold set at go-live goes stale and gets muted | The baseline moves as the person’s working pattern moves |
| A new account has nothing to be compared against yet | A decoy needs no history to fire |
| Every account is real, so every access looks plausible | Bait sits among the real ones, doing nothing, waiting |
| Coverage is asserted in a slide | Detections are mapped to MITRE ATT&CK techniques |
| The model produces a dashboard | It drives an isolation, a reset or a stronger challenge |
Frequently asked questions
What is user behaviour analytics?
Building a picture of how an account normally authenticates, and then measuring new sign-ins against that picture rather than against a fixed rule. It is sometimes called UEBA. The value depends entirely on what the comparison is made against — which is the part most descriptions leave out.
Why is a company-wide baseline not good enough?
Because almost nobody is average. An executive signing in from four countries a month, an engineer who works at three in the morning by choice, and a clerk who touches one system all day produce an average that fits none of them. Alerting on distance from that average buries the team, and the dangerous session hides in the middle rather than standing out from it.
Is our authentication data used to train a model for other customers?
No. Each account is scored against its own history, and the baseline for one organisation is built from that organisation's activity. What improves centrally is the detection engine — the rules, the techniques, the intelligence — not a model assembled out of your sign-ins.
What does the model actually look at?
Authentication behaviour: the spread of source addresses an account uses, the distance and time between consecutive sign-ins, the ratio of second-factor failures to successes, and when the account turns up compared with when it usually does. These are weighed together — no single one raises an alarm on its own.
Does Mirket care whether the phone itself is secure?
Yes. A registered device that has since been rooted or jailbroken has had its protections deliberately removed, so an approval from it is worth less than the same approval was at enrolment. It is read as device state rather than behaviour, which means it needs no history to be useful.
What is impossible travel?
Two sign-ins from locations far enough apart that nobody could have covered the distance in the time between them. It is a strong signal, not a verdict — a VPN exit point in another country produces the same shape, which is why it is weighed alongside everything else rather than acted on alone.
How long before the baseline is useful?
It depends on how much the account authenticates, which is the honest answer. An account that signs in several times a day establishes a shape quickly; one used monthly takes longer. That gap is exactly what deception is for — a decoy needs no history at all.
Does the baseline go stale as people change roles?
It updates as behaviour changes, which is the point of a learned model rather than a threshold. A rule written at go-live is wrong within a quarter and gets muted; a baseline that moves with the person stays usable.
What is identity deception?
Planting accounts and credentials that look like the privileged targets an attacker hunts for, and then never using them for anything. Because nothing legitimate ever touches them, an appearance in your authentication activity has very little else it can mean.
What is a decoy credential?
A password made to look real and valuable — the sort of thing found in a configuration file, a script or a password list — but which belongs to nothing. No application authenticates with it and no person knows it. Submitting one requires having collected it from somewhere it was left to be found.
What kinds of decoy can be planted?
Four. Credentials that belong to nothing, accounts nobody ever signs in as, enrolment pages that look like the way to register a device and lead nowhere, and applications that appear available but have no users. The last two catch somebody who is still looking rather than somebody who has already taken something.
Which detection carries the highest certainty?
The decoy. Every other detection has to weigh an innocent explanation against a hostile one — a flat battery against a stolen password, a business trip against impossible travel. A decoy has no innocent explanation to weigh, which is why it carries the highest certainty score Mirket assigns.
Doesn't a honeypot generate false alarms like everything else?
It can, and there are exactly two ways: somebody on your own team tests it, or a decoy is placed somewhere real work reaches. Both are placement problems rather than detection problems, and both are fixed once. That is a different kind of tuning from a behavioural threshold, which needs revisiting as people's habits change.
Where does Mirket see a decoy being used?
At the point somebody tries to authenticate with it, on the surfaces the platform itself handles. ITDR is an authentication-layer engine, not a network sensor, so it does not watch file shares or directory traffic. The equivalent control for credentials held by applications rather than people is NHI LDAP Proxy, where a virtual credential has the same property by design.
Can it see what somebody does after they sign in?
Whatever authenticates, yes — and that is more than it sounds, because raising privilege is itself an authentication event where Mirket protects elevation. What it cannot see is activity that never authenticates at all: traffic on the network, files being opened, work done inside a session already established. Account Takeover & Compromised Credential Detection sets out that boundary in full.
Does Mirket use machine learning, or is it rules with a label on?
It is a model, and a per-identity one. Nobody writes a rule for what normal looks like for a particular person — the model derives it from that account's own history and keeps revising it. Risk scoring is model-driven and improves as it sees more, and password spraying and credential sharing are analysed the same way rather than measured against a fixed count, because an attacker pacing themselves under a threshold is exactly the one a counter misses.
Is every detection a model, then?
No, deliberately. A decoy has no behaviour to learn and nothing to predict, so wrapping it in a model would add uncertainty instead of removing it — it should simply be exact. Choosing which detections are learned and which are deterministic is what makes the learned ones worth acting on.
How does this relate to MITRE ATT&CK?
Each detection is mapped to the technique it represents, so coverage can be reported against a recognised framework and gaps can be argued with evidence rather than asserted in a slide.
Why is ITDR only available as a service?
Because the model needs sign-in history to learn from, and a decoy is inert until somebody authenticates with it — both require an engine positioned to read your authentication activity. On your own servers that activity stays with you, which is a legitimate choice with a known consequence. Deployment sets out both.
Related
Solutions — Account Takeover & Compromised Credential Detection · Adaptive Authentication · MFA Fatigue Attacks · Privileged Account Discovery · LDAP Service Account Security
Products — Identity Threat Detection & Response · NHI LDAP Proxy