Two things a successful login will never tell you
1. The attempt that failed is the one you most need to see
Your MFA did its job. Somebody had the correct password for a real account, the second factor turned them away, and nothing was lost.
Nobody was told, because nothing broke.
But look at what that event actually says: the password is out. Someone, somewhere, is holding a credential that belongs to one of your people. And that raises questions a login screen cannot answer:
- When did it leave, and how? Phishing? A breach somewhere else, reused here? Something running on that person’s laptop?
- Where else does it work? If it was reused, it isn’t only your problem — and yours isn’t the only door it opens.
- Did whatever took it take anything else? A credential rarely leaves on its own. If malware lifted it, what else did the same malware reach?
A blocked sign-in is not a non-event. It can be an early signal that a valid credential is already in someone else’s hands — particularly when repeated attempts, an unfamiliar origin or other risk signals sit alongside it — and that is worth acting on the day it happens, rather than after the second factor eventually fails too.
2. The person who is already inside
Everything above is about somebody trying to get in. The harder problem is somebody who doesn’t have to.
An employee going through systems they have no business in. A contractor whose account is doing more than the contract covers. An attacker sitting on a session that was opened legitimately, with credentials that work, on a device that’s enrolled.
They authenticate correctly, because they can. They use accounts they’re entitled to use. Every individual action they take is permitted. No rule is broken, so no rule fires.
What gives them away isn’t a violation. It’s the shape of what they’re doing — where they’re coming from, at what hours, in what order, against systems this account has never touched before. That’s a behaviour question, and only something watching behaviour can answer it.
MFA bought you time. Knowing it happened is what lets you use that time.
How it works
It learns what normal is, and then watches for what isn’t
ITDR is not a separate system with its own view of the world. It reads the authentication events your Mirket tenant is already producing — sign-ins across MFA, SSO, the self-service portal and every surface in front of them — and builds a baseline per account rather than one rule for everybody.
That dependency is the point. There is no collector to deploy, no log format to map and no delay while yesterday’s events are shipped somewhere. It analyses the authentication because it is part of the thing doing the authenticating.
Four signals feed it:
- Behaviour. How this account normally signs in: when, from where, in what sequence, against which applications. A deviation is measured against this person’s history, not against a company-wide average that nobody actually matches.
- Origin. Where the request came from, and whether it arrived through TOR, a VPN, a proxy or a cloud provider. Anonymised origin isn’t proof of anything by itself — plenty of legitimate users have a VPN — but it changes the weight of everything else in the same session.
- Threat intelligence. Detections are enriched with known malicious infrastructure, actor intelligence and leaked-credential feeds — so a credential already circulating publicly can be refused at the point somebody signs in with it, rather than arriving as a list to work through. Each detection is mapped to the MITRE ATT&CK technique it represents, so coverage can be reported rather than asserted.
- Deception. Decoy accounts and credentials are planted in the environment. They have no legitimate use, so nobody has a reason to touch them by accident. Anything that does is either enumerating or moving laterally, and it has just announced itself.
The chain is covered end to end rather than at one point: credential harvesting → privilege escalation → account takeover. Catching it early is better, and catching it late is much better than not catching it.
Two scores, not one
A single score mixes two different questions: how serious the event would be if it is real, and how confident the platform is that it is. Collapse them into one number and you are left choosing a threshold, which is a trap: set it low and the team drowns in alerts, set it high and the detections that mattered most — serious, but not yet certain — never surface.
Mirket scores every detection and every account twice:
- Threat score — how serious this would be if it’s real
- Certainty score — how confident the platform is that it is
Those are different questions and they deserve different answers. Serious and certain can be responded to automatically with nobody in the path. Serious but uncertain shouldn’t be ignored and shouldn’t trigger an account isolation either — it should raise the challenge and reach a human. Minor but certain is worth recording, because three of them in a week is a pattern even though one of them isn’t.
Detection
The signal that fires when a password has already gone
There’s one pattern worth calling out on its own, because it is unusually clean.
A user passes the first factor and repeatedly fails the second.
Think about what that requires. Someone has the correct password — so this is not a guess, not a spray, not a typo pattern. And they do not have the enrolled device. Together, those two facts are a high-confidence indicator of possible credential compromise — with the second factor as the only thing still holding.
It isn’t proof on its own, and this page shouldn’t pretend otherwise. A user changes handset, a push doesn’t arrive, a code is mistyped, a device clock drifts. What separates the two is the shape: a real user fails, notices, and goes to fix it; an attacker working a list keeps going. The signal strengthens as it accumulates — repeated attempts over time, an unfamiliar origin, behaviour that doesn’t match the account’s own history.
Mirket raises it as a high-confidence credential-compromise detection and triggers the response policy you define — which for most teams means the password changes today, rather than after somebody works through a queue.
The other detections that carry their own weight:
| A decoy credential is used | It exists nowhere legitimate. Use is theft, not behaviour |
| Impossible sequence for the account | The pattern doesn’t fit this person’s history, not a generic rule |
| Anonymised origin on a sensitive action | TOR, VPN, proxy or cloud origin, weighted against what the session then tried to do |
| Escalation that doesn’t fit the role | Privilege sought by an account that has never sought it |
Response
An alert that waits for an analyst is a detection with an unknown delay attached to it. ITDR can act on its own:
| Isolate the account | Stop it being used while the situation is established |
| Force a password reset | Where the credential itself is the confirmed problem |
| Raise an adaptive MFA challenge | The proportionate answer to uncertainty: not blocking, not ignoring — asking again, harder |
Which response fires for which combination of scores is a policy decision you make once, not a judgment somebody makes at 3am.
See what your own sign-ins are already telling you
A technical demo on the authentication data the platform is producing today — a high-confidence credential-compromise detection, how it scores, and the response that fires without anyone reading a queue.
Why ITDR is delivered as a service
Every other Mirket module can run in your own data centre, and several of them run nowhere else. ITDR is the exception, and the reason is about how detection stays current rather than about what can technically be installed where.
A detection engine is worth exactly what its intelligence is worth on the day you’re attacked. Attack patterns, threat intelligence, behavioural models and ATT&CK mappings change continuously. Delivering ITDR as a service lets Mirket update detection logic across tenants as it changes, without waiting for a customer’s maintenance window or a platform upgrade. On a release cycle, the engine is always some distance behind the thing it is trying to catch, and the distance grows between upgrades.
Your baseline is still your own. Each account is scored against its own history — how that person normally signs in, from where, at what times — while the detection logic and threat intelligence are maintained at the service level. What improves centrally is the engine, not a model built out of your traffic.
And it only makes sense on top of authentication you’re already doing. ITDR has nothing to analyse unless sign-ins are passing through the platform — which is why it’s an add-on to MFA, SSO and Self-Service rather than something bought on its own. A detection layer with no authentication underneath it is a log reader.
Audit and compliance
Nobody’s product makes you compliant. These are the obligations identity detection is assessed against, and what ITDR offers towards each.
NIS2
Art. 21Detection, handling and reporting of incidents, with measures proportionate to the risk. Identity is where most incidents now begin
ISO/IEC 27001:2022
A.8.16Monitoring activities: networks, systems and applications monitored for anomalous behaviour, with appropriate action taken
PCI DSS v4.x
Req. 10.4Audit logs reviewed for anomalies and suspicious activity, with automated mechanisms doing the reviewing. Scored detections are that review, rather than a person reading yesterday's logs
PCI DSS v4.x
Req. 12.10Incident response: detecting an event, and acting on it. An automatic challenge, isolation or forced reset is the acting part, taken at the moment of detection
MITRE ATT&CK
Detections are mapped to techniques, so coverage can be reported and gaps can be argued about with evidence
Deployment
SaaS, as an add-on to the Mirket platform — and specifically to MFA, SSO and Secure Self-Service running as a service.
Those modules have to be in use for ITDR to have anything to work with, and they have to be the service deployment rather than the on-premise one, because that is where the sign-ins ITDR reads are produced.
Which is the part worth being precise about: ITDR doesn’t create a data flow of its own. If you are running MFA, SSO or Secure Self-Service as a service, those sign-ins are already being processed in the Mirket cloud as part of delivering the modules themselves. ITDR scores what is already there. It does not add an export, a second copy, or a pipeline out of your environment — and if you run those modules on your own servers instead, there are no cloud sign-ins for it to read, which is why ITDR belongs to the service deployment.
On data residency: the service is deployed regionally, and a tenant’s data stays in the region that tenant is provisioned in. Which region applies to you is settled when the tenant is set up.
There is nothing to install and nothing to size. No agent goes on an endpoint, no collector goes in your network, and no log pipeline is built. Detection and response act on the identity, in the same place the identity is already being authenticated.
Counted by defined users, and licensed as an add-on to the platform rather than as a standalone product.
