The identity provider quietly moved out of your data centre
Federation won. Applications stopped keeping their own passwords and started trusting one identity provider. That part is a solved problem, and it’s the right architecture.
What changed underneath it is where the identity provider lives. The large platforms are cloud-first — the identity provider is a service you rent, and every sign-in, every attribute, every assertion is evaluated on infrastructure someone else runs. For most organisations that’s a reasonable trade.
For yours, it may not be. If your directory is on-premise on purpose, if regulated data can’t leave the country, if the reason you run your own systems is that you don’t want the crown jewels in a rented platform — then federating every login to a cloud identity provider quietly undoes the thing you built the rest of your estate to preserve. The one system that decides who everyone is now sits outside the boundary you were defending.
The on-premise options that used to fill this gap have aged out. ADFS still runs in thousands of estates, but it’s a server role people maintain rather than a product anyone is investing in. And the direction of travel is unambiguous: Microsoft retired Azure MFA Server — its on-premise identity component — in September 2024. The message to anyone who wants identity on their own hardware was: move to the cloud.
Running your own identity provider didn’t become a bad idea. It just stopped being offered.
One question
Where does a login actually get verified in your environment — on hardware you control, or in a platform you rent? And if that platform had a bad morning, do you know which of your applications would stop?
If every federated application depends on an identity provider you don’t operate, then its availability and its jurisdiction are now yours to live with, not yours to decide.
Why the gap is hard to close
| Why it persists | What’s actually going on |
|---|---|
| The modern IdPs are cloud-first | The well-supported identity providers assume their cloud. Running one in your own data centre isn’t a configuration — it isn’t on offer. |
| ADFS is stuck in place | It works, so it stays, but nobody wants to extend it. New applications get bolted on to aging infrastructure because the alternative looks like a migration. |
| On-premise reads as legacy | “Keep it in our data centre” gets heard as “resist the cloud”, so the genuine reasons — sovereignty, regulation, control — get argued as preferences rather than requirements. |
| DIY is a maintenance sentence | Assembling an open-source identity provider yourself means owning its patching, its availability and its certificate lifecycle forever. So the gap stays open rather than becoming a second job. |
Measure how far your identity has already left the building
Two inventories, both quick, both revealing.
First, where each application’s identity lives. Walk your application list and sort each one:
| For each application | What to record |
|---|---|
| Keeps its own separate login and user list | An identity island — no federation, its own password to steal and its own leaver to miss |
| Federated to a cloud identity provider | Working, but its sign-ins and attributes are evaluated outside your environment |
| Federated to ADFS or an on-premise IdP | On your infrastructure — and worth checking what that infrastructure’s future is |
Then, count what ADFS is quietly carrying. If you run it, ask it how much depends on it:
Get-AdfsRelyingPartyTrust | Measure-Object | Select-Object Count
Get-AdfsRelyingPartyTrust | Select-Object Name, Enabled, LastUpdateTimeThat number is how many applications are riding a server role nobody is investing in. Read the LastUpdateTime column too — the trusts that haven’t been touched in years are the ones that will surprise you when the platform underneath them finally has to move.
What the two lists show together. Some of your identity has moved to a rented platform, and the rest is sitting on infrastructure with no roadmap. Neither is a decision anyone made deliberately — it’s where the absence of an on-premise option left you.
What an on-premise identity provider has to do
- It has to speak the modern standards. SAML 2.0, OAuth 2.0 and OpenID Connect — so it federates exactly the applications a cloud identity provider would, with nothing given up for running it yourself.
- Identity data has to stay on your infrastructure. The assertion is signed on your side, the attributes never leave, and the authentication decision is made on hardware you control. That’s the whole point of the exercise.
- It has to be a supported product, not a project. Escaping ADFS to maintain a different server role forever is not an escape. Someone else has to own the patching, the upgrades and the roadmap.
- It has to take over from ADFS in place. Migration can’t mean re-onboarding every application from a blank sheet. The relying parties have to move without each becoming its own project.
- It has to be highly available. An identity provider is now on the critical path for every federated application. A single box is a single point of failure for all of them at once.
- It has to be one platform with the second factor and privileged access. On-premise mustn’t mean stitching three vendors together — the IdP, the MFA and the access to servers should run on the same system.
How Mirket does it
Mirket is a full identity provider that runs in your own data centre — SAML 2.0, OAuth 2.0 and OpenID Connect, IdP-initiated and SP-initiated, signed assertions, single logout, attribute and group mapping into each application. It federates the same applications a cloud provider would, with the same standards. That’s requirement 1, with nothing traded away for keeping it home.
And keeping it home is requirement 2, answered by where the work happens: the assertion is signed on your infrastructure, the attributes are read from your directory, and the authentication decision never leaves your environment. For an organisation that keeps its data on-premise on purpose, the system that verifies identity now sits inside the same boundary as everything it protects.
It’s a supported product, not a server role you nurse — Mirket owns the upgrades and the roadmap, which is the difference between leaving ADFS and simply moving into another decade of maintenance. Requirement 3. Where ADFS is already in place, Mirket can also register as a second-factor adapter inside it during a transition, so moving off it is a path rather than a cliff — requirement 4.
Because the identity provider is now critical to every federated application, it runs as an active-passive high-availability pair — a second node kept in continuous sync that takes the service over automatically if the primary stops responding. Requirement 5.
And it’s one platform — the identity provider, the second factor, self-service and privileged access run on one installation over one set of users, which is what puts a server and a SaaS application on the same screen and lets a passwordless policy cover both. Requirement 6, and the reason on-premise here doesn’t mean assembling a stack.
What changes
| Today | After |
|---|---|
| The identity provider runs in someone else’s cloud | It runs in your data centre |
| Assertions and attributes are evaluated outside your boundary | They’re signed and evaluated on your infrastructure |
| New applications get bolted onto ADFS | They federate to a provider with a roadmap |
| Leaving ADFS looks like a migration | Its relying parties move without starting over |
| The IdP is a single server every app depends on | It’s an active-passive pair |
| On-premise identity means assembling it yourself | It’s one supported product |
Related
Solutions — Passwordless Authentication · Adaptive Authentication · MFA for Legacy Applications · VPN & Firewall MFA
Products — Single Sign-On · Multi-Factor Authentication