Not every login deserves the same authentication challenge
The same employee signs in from the same managed device, on the same network, during normal working hours. Later, the same account appears from an unfamiliar device, an unusual country, or an anonymised network.
A fixed MFA policy can challenge both of those in exactly the same way. Adaptive authentication doesn’t have to.
Reduce unnecessary friction when the context is trusted. Raise the requirement when risk increases. Refuse when the evidence is strong enough.
One question
How much authentication does your safest login get, and how much does your riskiest one get?
If the answer is “the same”, the policy isn’t using the context that is already present at sign-in.
Authentication that changes with the login
Mirket evaluates the context available at the moment of authentication and changes what happens next according to policy.
Two layers sit behind that picture, and they are worth keeping apart because they run in different places. Context-based policy is part of the authentication platform and works on either deployment. Behavioural risk comes from Mirket ITDR, which reads the sign-ins the service platform produces.
Use the context already present at sign-in
- User and group Different requirements for different identities — a finance team held to a stricter method than a warehouse shift.
- Device A recognised, enrolled device is a different proposition from one that has never been seen before.
- Network and source Source address and network are part of the decision, not just an allowlist gate in front of it.
- Schedule Requirements can change by time of day or day of week, including one-off windows.
- RADIUS client Which gateway the request arrived through can carry its own rule.
- Country Geographic origin of the request, on the service platform.
These are conditions inside the authentication rule itself, so they apply wherever Mirket authenticates — and each surface keeps its own rule set rather than inheriting one global policy.
Go beyond context with behavioural risk
Context tells you what is happening now. Behaviour tells you whether it is normal for this identity.
Mirket ITDR builds a baseline per account and scores authentication activity against that account’s own history rather than a company-wide average that nobody actually matches.
- The account's own baseline A 3am sign-in is unremarkable for someone who works nights and significant for someone who never has. The comparison is per identity.
- Origin intelligence TOR, VPN, proxy and cloud-provider origins are identified and weighed. An anonymised origin is not proof of anything by itself — it changes what the rest of the session has to look like.
- Account-takeover signals Combinations of authentication and behavioural evidence that, together, indicate an account may no longer be in its owner's hands.
- Deviation detection Meaningful changes in location, timing and authentication pattern — measured as change, not as a fixed threshold.
Risk is not one number
A suspicious event can be serious without being certain, or certain without being serious. Treating those the same produces either unnecessary blocks or unnecessary exposure — which is why Mirket scores each detection twice.
- Threat Score How serious would this be if the detection is correct?
- Certainty Score How confident is Mirket that the detected behaviour is what it appears to be?
| High threat · high certainty | Refuse, or isolate the account |
| High threat · lower certainty | Raise the challenge rather than block — the cost of being wrong is a step-up, not an outage |
| Lower threat · high certainty | Record it, and let policy decide whether anything else follows |
Separating severity from confidence lets the response match the evidence. A single blended score has to pick one number for two different questions, and then a threshold has to be set against it — which is how a genuine detection ends up either ignored or over-enforced.
Make the response match the risk
- Allow Let authentication continue on the usual method when policy and context indicate low risk.
- Step up Require a stronger method when the login deserves more verification than usual.
- Refuse Stop the authentication when policy or risk evidence crosses the configured line.
- Respond With ITDR: isolate the account, force a password reset, or raise the challenge — automatically.
The objective is not more authentication. It’s the right authentication for the login in front of you.
When repeated MFA failure becomes a signal
A password accepted, followed by a run of failed or rejected second factors on the same account, is usually filed as MFA working. Read against the account’s normal behaviour it can mean something closer to the opposite: somebody holds the first factor and is working on the second.
Where ITDR is running, that pattern is evaluated alongside the account’s wider behaviour instead of being counted as a series of unrelated failures — and the response can rise as the pattern develops. MFA Fatigue Attacks covers the attack itself and what it looks like from the user’s side.
Adapt to the access path
A VPN login, a browser sign-in and an operating-system logon do not expose the same information. Mirket lets each rule use what its own access path actually provides rather than forcing every surface through one global rule that has to be written for the weakest of them.
| Access path | What the rule can read |
|---|---|
| VPN and network devices | User and group · RADIUS client · source address · schedule · method per target |
| Web and federated applications | Identity · device · source · schedule · authentication context |
| Operating-system access | Identity · device · logon type — local, remote, unlock or elevation |
Adaptive authentication on-premise or as a service
This is the distinction worth being precise about, because “adaptive authentication” is often assumed to mean a cloud-only risk engine.
| Capability | On-premise | As a service |
|---|---|---|
| User and group conditions | ✓ | ✓ |
| Source address and network | ✓ | ✓ |
| Device conditions | ✓ | ✓ |
| Schedule conditions | ✓ | ✓ |
| RADIUS client conditions | ✓ | ✓ |
| Bypass controls | ✓ | ✓ |
| Source country | — | ✓ |
| Behavioural baseline per account | — | ✓ with ITDR |
| Threat and certainty scoring | — | ✓ with ITDR |
| Automated response | — | ✓ with ITDR |
An on-premise deployment is adaptive. The rules turn on identity, device, network, gateway and time, and each surface carries its own set. What it does not have is the behavioural layer: ITDR scores the sign-ins the service platform produces, so it applies where MFA, SSO or Secure Self-Service run as a service. Which shape suits your environment is worked through on Deployment.
Why fixed authentication falls short
- Context goes unused The decision is made without the information already present at sign-in — who, on what device, from where, at what hour.
- Behaviour is invisible A login can be unremarkable for one identity and extraordinary for another. A static rule cannot see the difference, because it has no idea what normal looks like for this person.
- The response is binary Challenge or allow. A risk-aware decision needs a third answer — and a fourth, when something should be stopped rather than questioned.
What changes with Mirket
| Fixed authentication | Adaptive authentication |
|---|---|
| Every login receives the same challenge | The requirement changes with context and risk |
| A known device and an unknown one are treated alike | Device context can change what is asked for |
| Location is ignored, or reduced to an allowlist | Country and source become part of the decision |
| Individual behaviour plays no part | ITDR compares activity with the identity’s own baseline |
| Risk is one number against one threshold | Severity and confidence are scored separately |
| The answer is challenge or allow | Allow, step up, refuse — or trigger a response |
| A risky sign-in waits for someone to investigate | The configured response fires on its own |
Frequently asked questions
What is adaptive authentication?
Authentication that changes with the circumstances of a sign-in rather than applying one rule to every attempt. A login that matches the usual pattern can pass with less friction; one that doesn't can be challenged harder or refused.
Is adaptive authentication the same as risk-based authentication?
They overlap but they are not the same. Adaptive describes changing the requirement according to contextual policy — who, from where, on what device, at what time. Risk-based describes using an evaluated risk signal to influence that decision. Mirket does the first on either deployment, and adds the second through Mirket ITDR.
What signals can Mirket use for adaptive authentication?
In the authentication policy itself: user and group, source address and network, device, RADIUS client and schedule — and source country on the service platform. Where ITDR is running, the account's own behavioural history and origin intelligence join the same decision.
Can Mirket require stronger authentication only when risk increases?
Yes. A rule can let a familiar context through on the usual method and require a stronger one when the context changes — a device that has not been seen before, an unfamiliar country, an attempt outside the schedule the account normally keeps.
Can Mirket refuse a risky authentication outright?
Yes. Refusal is one of the three outcomes a rule can reach, and with ITDR it can also be reached from the risk evaluation rather than only from static policy.
Does Mirket detect TOR, VPN and proxy traffic?
Mirket ITDR identifies TOR, VPN, proxy and cloud-provider origins and uses them to weight the wider risk picture. An anonymised origin is not treated as proof of compromise on its own — plenty of legitimate users sit behind a VPN — but it changes what the rest of the session has to look like before it is trusted.
What are Threat Score and Certainty Score?
Two separate numbers for two separate questions. Threat Score is how serious the activity would be if the detection is right; Certainty Score is how confident Mirket is that the detection is right. Keeping them apart lets a serious-but-uncertain case raise the challenge instead of blocking, which one combined number cannot express.
Does adaptive authentication work on-premise?
Yes, for the context-based layer — user and group, source address and network, device, RADIUS client and schedule all apply in an on-premise deployment. The behavioural layer comes from ITDR, which reads the sign-ins the service platform produces, so it applies where MFA, SSO or Secure Self-Service are running as a service.
Does ITDR require the rest of Mirket to run as a service?
Yes. ITDR scores authentication activity that the service platform is already processing, so it applies where MFA, SSO or Secure Self-Service run as a service. An on-premise deployment keeps the context rules; it does not gain the behavioural layer. The two shapes are set out on Deployment.
Can adaptive authentication reduce MFA fatigue?
In two ways. It can stop spending challenges on contexts that are demonstrably ordinary, which is where approval-by-reflex comes from in the first place. And where ITDR is running, a run of failed or rejected challenges on one account can itself be read as a signal rather than as MFA doing its job. MFA Fatigue Attacks covers the attack in full.
Can the response happen without an analyst?
Yes. With ITDR the configured response fires on its own — raising the challenge, forcing a password reset, or isolating the account — so a risky sign-in is not waiting in a queue for somebody to read an alert.
Related
Solutions — MFA Fatigue Attacks · Account Takeover & Compromised Credential Detection · User Behaviour Analytics & Identity Deception · VPN & Firewall MFA
Products — Multi-Factor Authentication · Identity Threat Detection & Response