Which open-source alternative to Microsoft Entra ID fits your situation
For most general SSO and federation work, Keycloak is the first option to evaluate. It supports OpenID Connect, OAuth 2.0 and SAML 2.0 and has built-in user federation with existing LDAP and Active Directory servers, so it can sit in front of your current directory while applications move over. *authentik* fits teams that want a flexible provider and proxy model, especially for applications without native SAML or OIDC support, and its free edition covers OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication with community support only. FreeIPA fits Linux-heavy environments that need a directory, Kerberos, certificate management and host policy in one system, and it can form trusts with Microsoft Active Directory.
Teams usually look for alternatives because of a renewal, a data residency requirement, a desire to reduce dependence on one vendor, or a change in how identity features are packaged. Whatever the trigger, confirm which Entra features you rely on today: conditional access, device compliance, B2B guest access, and Microsoft 365 sign-in are the ones most likely to need a replacement plan or to remain tied to Microsoft. Ask each candidate vendor or project to show, in writing, how it covers the protocols and directory sources your applications use, and where a feature is only available in a paid tier. Keep in mind that authentik's Microsoft Entra ID integration is listed among its Enterprise features, so confirm what that integration does before you rely on it.
Before choosing, inventory your applications by protocol and by how they authenticate, then test two or three of them against each candidate in a non-production realm or instance. Pay attention to group mapping, attribute names and how MFA enrollments carry over, because these tend to need the most rework. Your decision should also weigh who will run the platform: Keycloak and authentik are both self-hosted and need patching, backup and monitoring, and FreeIPA needs Linux administration skills. A sound choice is the one your team can operate and evidence to an auditor, not the one with the longest feature list.
Open-source options that can replace Entra ID SSO and directory duties
Entra ID covers two jobs: single sign-on for applications and a directory of users and groups. Keycloak, authentik, ZITADEL and FreeIPA each cover a different part of that work, so the right choice depends on whether you need an SSO broker, a Linux-centric directory or a multi-tenant identity service. The cards below set out what each option does and the trade-off you should weigh before shortlisting.
Keycloak for broad SSO
Keycloak is licensed under the Apache License 2.0 and is a Cloud Native Computing Foundation incubating project. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can federate with existing LDAP and Active Directory servers, so it can sit in front of your current directory while applications move over. Version 26.8.1 was released on October 13, 2026. The trade-off is that you own the operations: clustering, upgrades and backups are your team's job, and the realm export and import tooling has documented limits as a backup method. Confirm your federation and MFA requirements in a lab before you commit.
authentik with a split license
authentik's open-source core is MIT licensed, but its enterprise directory features sit under a separate authentik EE License. The free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication, with community support only. Enterprise adds integrations such as Microsoft Entra ID and ticket-based support, which may matter if you keep Entra as an upstream source. Map each Entra feature you rely on to either the MIT core or the EE license before assuming parity.
ZITADEL for multi-tenant identity
ZITADEL is licensed under AGPL-3.0, with Apache 2.0 and MIT exceptions for specific directories. It supports certified OIDC, SAML 2.0, SCIM 2.0 and LDAP, and it self-hosts with Docker Compose or Kubernetes on PostgreSQL 14 or later. Its structure of Identity System, Organizations and Projects isolates data and policies at several levels, which suits customer-facing or multi-tenant use. The trade-off is licensing: AGPL-3.0 obligations can apply if you modify and offer the software over a network, so have legal counsel review the license against your deployment model.
FreeIPA for Linux directories
FreeIPA is an integrated identity and access management solution for Linux. It combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD, and it can create mutual trusts with Microsoft Active Directory. It fits organizations with many Linux hosts that need Kerberos, host-based policy and internal certificates. It is less of a drop-in for modern browser SSO to SaaS applications, so the trade-off is that web and SAML or OIDC app coverage usually needs a companion product. Confirm which of your SaaS apps need SAML or OIDC before treating FreeIPA as an Entra replacement.
How each Entra ID capability maps to open-source coverage
This table maps the main Entra ID capabilities to Keycloak, authentik, ZITADEL and FreeIPA, with a coverage level and a note on what to confirm in each vendor's documentation. Read the coverage column as a starting point for a proof of concept, not a finished compatibility answer. Rows marked as unconfirmed need a check in the vendor docs before any migration decision.
| Entra ID capability | Open-source option and coverage | What to confirm |
|---|---|---|
| SSO to SAML and OIDC applications | Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0. Full coverage for standard federation. | Test each enterprise application's metadata, claims and signing certificate rotation in a non-production realm. |
| User directory and group management | Keycloak and authentik manage users and groups natively. FreeIPA provides a Linux-oriented directory with groups and host management. | Confirm nested group behavior and attribute mapping for the fields your apps read, such as department and manager. |
| LDAP and Active Directory federation | Keycloak has built-in user federation with existing LDAP and Active Directory servers. authentik supports LDAP. FreeIPA can create mutual trusts with Microsoft Active Directory. | Verify read-only versus write-back modes, and whether password validation stays with the source directory. |
| SCIM provisioning | authentik free edition and ZITADEL support SCIM. Keycloak SCIM support depends on extensions or the version in use. | Check which SCIM resources and operations each product supports, and which extensions you need for Keycloak. |
| MFA and conditional access | Not confirmed by the supplied sources for conditional access. Keycloak and authentik both document MFA-related features, but policy-based conditional access parity with Entra ID is not established here. | Ask each vendor to document MFA methods, risk-based rules and device conditions, and test them against your current Entra policies. |
| Kerberos and Windows domain logon | FreeIPA combines 389 Directory Server with MIT Kerberos, Dogtag and SSSD for Linux. authentik free edition lists Kerberos authentication. | Windows domain logon and GPO-style device management are not covered by these sources. Confirm with your AD or Windows management plan. |
| Windows device management | No supplied source confirms an open-source equivalent to Intune or Entra device join. Treat this as a gap. | Decide which Windows management tooling stays in place and whether devices still need Microsoft-side enrollment. |
| Application proxy for on-premises apps | authentik free edition supports proxy authentication. Keycloak and ZITADEL do not provide a described equivalent in the supplied sources. | Confirm the proxy mode, header handling and load balancer requirements, and whether the proxy is in the free edition. |
| Microsoft 365 sign-in and licensing | Not replaceable by these options. Exchange, Teams and Office sign-in depend on Microsoft's own identity services and licensing. | Plan whether Microsoft 365 keeps Entra ID as its identity source, and how federated domains are handled. |
What stays tied to Microsoft 365 when you move identity
Moving SSO and directory duties off Microsoft Entra ID does not move Microsoft 365 with them. Exchange, Teams, SharePoint and Office licensing depend on Entra ID and on their own tenant settings, so each of those services keeps its trust relationship and configuration until you change it deliberately. Treat the Microsoft 365 tenant as a separate system in your migration plan, with its own owner, change window and rollback path. Before you pick between Keycloak, authentik or FreeIPA for workforce login, confirm which Microsoft 365 workloads your users depend on day to day and which of them rely on Entra ID for sign-in, licensing or device management.
If Microsoft 365 keeps trusting a different identity provider, the domain must be federated with that provider, which changes how sign-in is routed for every user on the domain. Microsoft documents the federation and domain settings in its own tenant guidance, and you should read those pages with your Microsoft partner or account team before any change. Plan for the on-premises sync path too, since users provisioned from a directory will need their identifiers, including the userPrincipalName and mail attributes, to match what Microsoft 365 expects. Test sign-in for a pilot group, including mobile clients and legacy protocols, before you move the domain.
The authentik Enterprise edition includes an Entra ID integration, according to the authentik pricing page, so it is one route for keeping Microsoft-facing and self-hosted applications in one flow during a transition. Check whether that integration covers the Microsoft 365 scenarios you need, such as federation or provisioning, and get the answer in writing. Confirm with Microsoft which licenses, conditional access policies and tenant settings must be kept, changed or removed, and ask who signs off each change. Do not assume that a self-hosted identity provider changes Microsoft 365 licensing or support terms.
Migration steps from Entra ID to a self-hosted directory
This sequence moves identity from Microsoft Entra ID to a self-hosted directory in controlled stages, so each application is proven before its users depend on it. The end state is a documented inventory, a tested user and attribute model, and a decommissioned Entra tenant dependency for the applications in scope.
Inventory applications and protocols
The identity owner and application owners list every app that signs in through Entra ID, the protocol each uses (OIDC, OAuth 2.0, SAML 2.0, LDAP or Kerberos), its redirect URIs or metadata, its MFA requirements, and whether it depends on Microsoft 365 services such as Exchange, Teams or SharePoint. Apps that need Microsoft-hosted features are flagged separately, because those features stay tied to Microsoft 365 regardless of the directory you choose. The inventory is done when every application has an owner, a protocol and a target cutover group.
Export the user list from Entra
An administrator signs in to the Entra admin center, opens Users, selects All users, and chooses Download users to produce a CSV. The file includes attributes such as userPrincipalName, mail, department and on-premises identifiers. Confirm with the Microsoft Learn article on downloading user lists which attributes the file includes in your tenant, and confirm that it does not contain passwords, MFA methods or other credential material. Store the export in a restricted location and record who ran it and when. The export is complete when the row count is reconciled against the tenant's active user count.
Map attributes to the target directory
The team maps each Entra attribute to its counterpart in the target platform, whether that is a Keycloak realm user profile, an authentik user attribute, or a FreeIPA user entry with its UID, mail and Kerberos principal. Identifiers that other systems rely on, such as employee IDs and on-premises SIDs or immutable IDs, are mapped deliberately. Group and role membership is mapped separately, since the CSV export does not describe it. The mapping is done when a reviewer signs off a written table covering every attribute and every downstream consumer.
Pilot with a small application group
The team builds the target realm or tenant, connects a test group of users (for example, a small internal group of volunteers, not production accounts), and moves two or three low-risk applications to the new directory. Protocol settings, claim mappings, logout behavior and session lifetimes are tested end to end. Where the directory is federated with an existing Active Directory, the federation path is tested as well. The pilot is closed when each application has a recorded sign-in test, a rollback procedure, and a list of defects with owners.
Run the directories in parallel
Entra ID and the self-hosted directory run side by side for a period agreed by the steering group, while applications are configured to accept either. Provisioning changes are made in the system of record and synchronized to both sides, and help desk staff use a documented runbook for password resets and MFA re-enrollment. Monitoring covers failed sign-ins, token errors and directory sync lag. The parallel run ends when sign-in failure rates are reviewed against the pilot baseline and the steering group approves the next cutover wave.
Cut over applications one at a time
Each application or small group moves to the self-hosted directory in its own change window, with its redirect URIs, client secrets and certificates updated and its Entra enterprise application disabled only after the new sign-in has been verified. Users are told in advance that they may be asked to set a new password or enroll MFA again, because Entra credentials and MFA methods do not move through a directory export. Confirm the re-enrollment process with Microsoft documentation and with each MFA vendor before the first wave. Each cutover is closed when its owner confirms sign-in and the rollback window has passed.
Decommission Entra dependencies
Once every application in scope has moved, the team removes the Entra enterprise applications and app registrations for those services, revokes the client secrets and certificates that were issued for them, and updates the directory sync, the licensing inventory and the access reviews. Services that still depend on Microsoft 365 remain in place and are documented as exceptions. Retained audit logs and the final user export are stored according to your records policy. Decommissioning is complete when the inventory shows no active Entra dependency for the in-scope applications and the change record is signed by the identity owner.
What Entra ID replacement costs over several years
This table compares the cost components on the Entra ID side and the self-hosted side, marking each as one-time or recurring and naming what drives it. Use it to build a multi-year model from your own Microsoft agreement and a written DeployOpen scope, not from list prices.
| Cost component | Who is paid or who pays | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Entra ID licensing | Microsoft, under your own agreement | Recurring | Licence tier, number of users, and which Microsoft 365 or Entra features you keep. Take the figures from your Microsoft agreement, since no price is supplied here. |
| Hosting and high availability | Your cloud provider or data center | Recurring | Number of nodes, database sizing, regions, load balancing and failover design for Keycloak, authentik or FreeIPA. |
| Implementation and migration | DeployOpen or your internal team | One-time | Number of applications, protocols (SAML, OIDC, LDAP, Kerberos), user attributes to map, and cutover waves. Confirm the scope in writing. |
| Support tier | Community, vendor enterprise plan, or DeployOpen retainer | Recurring | Community support is free but unscheduled. authentik Enterprise and Enterprise Plus add ticketed support and SLAs, so ask each vendor for its current terms. |
| Upgrades and backups | Your team or DeployOpen under a retainer | Recurring | Release cadence of the chosen platform, such as Keycloak's regular releases, plus backup tooling and restore testing. Keycloak's export and import is documented as a limited backup method, so budget for a separate backup design. |
| Compliance evidence | Your team, DeployOpen, and independent auditors | One-time and recurring | Number of controls in scope, logging retention, and access reviews. DeployOpen prepares evidence, but auditors and certification bodies issue reports. |
| Internal staff skills | Your payroll | Recurring | Identity engineering skills in-house, on-call coverage, and the number of regions and environments you run. |
What you give up when you leave Entra ID and the usual workarounds
Moving SSO and directory duties off Entra ID changes who runs the platform, who patches it and where support comes from. Each trade-off below has a workable answer, but each one carries a cost or a check that belongs in the migration plan before cutover.
Managed uptime and vendor-run infrastructure
Entra ID runs as a Microsoft-operated service, so your team does not size clusters, plan database failover or manage the identity tier's availability. A self-hosted Keycloak, authentik or FreeIPA deployment puts those duties on your platform team. Ask for a written high availability design covering load balancers, database replicas and a tested failover runbook. The uptime target must be set by your own service levels, not inherited from the old vendor.
Native Microsoft 365 and Windows integration
Entra ID is the sign-in authority for Microsoft 365, Windows device join and many Microsoft-hosted SaaS apps. Those integrations do not move with the directory. A common workaround is a hybrid period in which Entra ID stays the identity source for Microsoft 365 while Keycloak or authentik federates line-of-business and custom applications. Confirm which Microsoft services your tenant depends on before deciding the scope.
Conditional access and identity protection
Entra ID offers conditional access policies and risk-based identity protection as managed features. Open-source options provide policy and step-up authentication mechanisms, but the equivalent risk signals and policy templates vary by product and edition. Ask each candidate vendor to demonstrate your specific policies, such as location-based rules, device compliance checks and sign-in risk responses, and write down any policy you must rebuild as custom code.
Community-only support on free editions
Free open-source editions come with community support, with no contractual response times. authentik's free edition, for example, is community supported, while its paid tiers add ticket-based support and SLAs. Before go-live, decide who answers a severity-one login outage at 2 a.m. Options include a paid vendor support tier, a DeployOpen retainer covering operations and incident response, or an internal on-call rota with runbooks.
Internal ownership of upgrades and certificates
Microsoft handles service patching and the signing certificates behind Entra ID federation. With self-hosted platforms, your team owns version upgrades, TLS certificates, SAML signing keys and Kerberos keytabs in FreeIPA. Build a dated upgrade calendar, a certificate renewal inventory with alerts, and a key rotation procedure that is tested in staging. A DeployOpen retainer can cover upgrades and certificate operations on that calendar.
Which option fits your situation: residency, cost, Linux or regulated
When the driver is where identity data lives, the question is less about features and more about where the directory, the database and the backups can physically run. Keycloak is usually the first option to evaluate here because it runs on infrastructure you choose, supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can federate with existing LDAP and Active Directory servers during a phased move. ZITADEL is a credible alternative when you also need organization-level isolation.
- Decide the hosting boundary first: confirm whether the identity store must stay in a specific country, cloud region or data center, and whether support staff can access it remotely.
- Map every copy of the data: include the directory, the Keycloak database, logs, and backups, since each one can fall under the residency rule.
- Check federation paths: Entra ID sign-in traffic may still reach Microsoft for Microsoft 365 apps, so list which flows must stay inside the boundary.
- Plan the realm or tenant layout: a single realm per residency zone is often simpler to audit than mixing regions.
- Confirm export and restore limits: Keycloak's realm export is documented as having limitations as a backup mechanism, so design backups deliberately.
Before committing, ask DeployOpen or your own team to confirm how your residency requirement applies to log retention and support access.
When a licensing change prompts the move, the decision turns on which costs recur and who carries them. Self-hosted Keycloak is licensed under Apache License 2.0, and authentik's core is MIT licensed, so software licensing is not the main cost. The real costs are the infrastructure you run, the staff time to operate it, and any paid support or enterprise tier you choose to add. authentik Enterprise, for example, adds features such as Microsoft Entra ID integration and ticket-based support, which changes the cost picture if you need them.
- Separate one-time from recurring costs: migration engineering, testing and cutover are one-time; hosting, patching, on-call and upgrades recur.
- Count the features you actually use: if you need only SSO and LDAP, the free editions may cover you, but community support carries no guaranteed response.
- Price your operating model: the main cost driver is how many people must run the platform and how often you upgrade.
- Ask vendors for written quotes: request the enterprise feature list, support terms and any SLA in writing before comparing totals.
- Watch for hidden exits: if a platform cannot export password hashes or user data cleanly, your exit cost becomes a future cost.
Compare a three-year view of total cost, including your own staff hours, rather than the license line alone.
When the estate is mostly Linux servers, Kerberos authentication and host-based policy, FreeIPA is the option built for that world. It combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD in one integrated identity and access management solution, and it can create mutual trusts with Microsoft Active Directory. That makes it a natural fit for keeping Linux logins, sudo rules and host certificates in one place while Windows users stay in AD.
- Decide who owns the directory: confirm whether Linux administrators will run FreeIPA as the source of truth or only as a Kerberos realm alongside AD.
- Map the trust model: determine whether you need a one-way or two-way trust with Active Directory and which groups cross it.
- Inventory SSSD clients: list which hosts, containers and appliances authenticate through SSSD or Kerberos, since each one changes during cutover.
- Plan certificate lifecycles: Dogtag issues certificates, so decide which internal CAs and renewal processes you will keep.
- Keep web SSO separate: FreeIPA is strongest for host and Kerberos access, so pair it with Keycloak or authentik if browser SSO to SaaS apps is also required.
Confirm with your Linux team how many hosts depend on Kerberos today, because that count drives the testing scope.
When your team needs custom login flows, unusual claims, or application-specific policy, the choice is between platforms built for extension. Keycloak supports custom authenticators, protocol mappers and user federation providers, and suits teams that are comfortable writing Java extensions. authentik offers a flow-based model in Python with a lighter operational footprint for many teams. Both can replace Entra ID for the applications that matter most, but the customization effort should be scoped before the platform is chosen.
- Define the custom behavior: list each login flow, claim transformation and provisioning rule Entra ID handles today, including conditional access logic.
- Choose the extension language: confirm whether your developers prefer Java (Keycloak) or Python-based flows (authentik).
- Test upgrade impact: custom code must survive version upgrades, so plan a regression suite for each flow.
- Decide where customization stops: keep MFA, password policy and account lifecycle standard where possible to limit maintenance.
- Budget for ownership: custom components are maintained by whoever writes them, so name that owner before work starts.
Ask DeployOpen or your team to confirm which Entra ID policies have a direct equivalent and which need a custom build.
When an auditor or regulator will assess your identity controls, the platform must produce evidence that access was granted, reviewed and revoked as documented. Any self-hosted option can meet that need if the logging, access reviews, change records and backups are designed for it. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
- Define the control set first: agree with your auditor which controls map to identity, such as account lifecycle, privileged access and MFA enforcement.
- Plan log retention and integrity: confirm where authentication logs go, how long they are kept and who can alter them.
- Document the exit and restore path: show that backups restore and that realm or directory exports are tested, given the documented limits of Keycloak's export process.
- Prepare access review evidence: export user lists and group memberships on a schedule, and keep the records.
- Confirm assessor expectations: ask your auditor which evidence formats and sampling they accept before building reports.
Request a written scope from DeployOpen that names the controls and evidence it will prepare, and confirm the assessment itself with your independent auditor.
Questions buyers ask before replacing Entra ID
How much effort does moving off Entra ID take?
Effort depends mainly on how many applications depend on Entra ID, how many users and groups must move, and whether users sync from on-premises Active Directory. Each application that uses SAML or OpenID Connect needs its client registration, claims and logout settings rebuilt in the new platform, and each one needs testing. Hybrid environments add work because Entra Connect or its replacement must keep the directory in step during cutover. MFA re-enrollment is often the largest user-facing effort, because most methods registered in Entra ID do not carry over. Ask any partner to inventory applications and directory sync before quoting, since that inventory sets most of the scope.
Can our internal team run this migration without outside help?
Yes, many teams do, provided they have engineers who understand OpenID Connect, SAML, LDAP and their own directory structure. Keycloak, authentik and FreeIPA each have public documentation, and the Keycloak server guide covers realm import and export. The harder parts are usually cross-team: application owners must test their own login flows, and someone must own the MFA and password reset policy. Teams without this in-house experience often bring in an implementation partner for the design and cutover, then run the platform themselves. DeployOpen plans, implements, integrates and documents self-hosted platforms in the client's own infrastructure, and the scope is agreed in writing before work starts.
How long does an Entra ID migration take?
No fixed duration applies to every environment, so treat any single number as unverified until a written plan exists. The timeline is set by the number of applications, the complexity of their login integrations, the amount of on-premises directory sync, how many users must re-enroll MFA, and how many change windows the business allows. A phased cutover, moving one application group at a time, usually takes longer than a single switch but reduces risk. Ask for a phase-by-phase plan with named dependencies and a rollback step for each application group.
What does our staff need to contribute?
Internal staff usually provide four things: an accurate application inventory, access to the identity and directory administrators who can approve changes, application owners who can test sign-in and logout, and a decision maker for MFA and password policy. Security and compliance leads should also review the access model and evidence requirements. Staff time is one of the largest hidden costs, so ask a partner to list each internal role and the hours it needs during design, cutover and hypercare. Clear ownership before the project starts prevents most delays.
Does replacing Entra ID mean changing Microsoft 365?
Not necessarily. Microsoft 365 can continue to use Microsoft Entra ID for sign-in, and the replacement platform does not have to take over that role. Many organizations keep Microsoft 365 on Entra ID and move other applications to Keycloak, authentik or FreeIPA. Full replacement is a separate decision that affects Exchange Online, Teams, SharePoint, licensing and device management. authentik's free edition does not include a Microsoft Entra ID integration, which is part of its Enterprise tier, so check that feature set against your requirements. Confirm with Microsoft and your licensing agreement which Microsoft 365 identity features depend on Entra ID before you decide.
How do we export the user list from Entra ID?
Entra ID lets administrators download the user list as a CSV from the Entra admin center: open Users, select All users, then choose Download users. The file includes attributes such as userPrincipalName, mail, department and on-premises identifiers. Review the export before import, because it does not contain passwords or MFA registrations, and group memberships and application assignments need separate exports. Confirm the current export steps and attribute list in Microsoft's documentation, since the admin center changes over time. Store the file in an access-controlled location and delete copies once the import is verified.
What compliance evidence can DeployOpen prepare?
DeployOpen prepares systems, controls and evidence for compliance assessments, including access control configuration, documented identity processes, logging settings and test results. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that assessment. Before the project, ask which control frameworks apply to your organization, which identity controls the auditor will sample, and which evidence the auditor expects in what format. Confirm those requirements with your auditor, then agree the evidence list in the written scope.
Which identity controls should we verify after cutover?
Verify that each application enforces its own session timeout and logout, that MFA policies apply to the right groups, and that disabled accounts lose access in every connected system. Check that directory sync from Active Directory or LDAP does not recreate deactivated users, and that privileged accounts are reviewed on a schedule. Confirm that audit logs reach your central logging system. Keycloak exports realms as JSON, but its documentation warns that export is not a complete backup and restore method, so define a separate backup process before relying on the new platform.
How DeployOpen scopes, migrates and supports the Entra ID replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For an Entra ID replacement, we start from a written scope that names the applications, directories and Microsoft 365 dependencies that move, and we keep the work fixed-scope and agreed in writing before it starts.
How we scope
- Inventory every application that uses Entra ID for SAML, OIDC or LDAP sign-in and record its current configuration.
- Map Entra ID directory attributes, groups and on-premises sync dependencies to the target platform, whether Keycloak, authentik or FreeIPA.
- Define in writing what stays tied to Microsoft 365, such as Exchange Online, Teams and licensed Microsoft services, and what is out of scope.
How we build
- Deploy the chosen platform in your environment and configure user federation with existing Active Directory or LDAP sources where needed.
- Reconfigure each application's federation settings and test sign-in, token claims, group mappings and MFA enrollment before cutover.
- Run security testing against the identity platform and its integrations, and document the configuration, controls and evidence collected.
How we hand over
- Export the user list from the Entra admin center (Users, All users, Download users) and reconcile it against the target directory.
- Deliver runbooks for user lifecycle tasks, backup procedures and the export and import steps for realms or tenants, including their limits.
- Walk your operations and security teams through the running system and agree on the acceptance criteria in the written scope.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan platform upgrades and patch cycles against the vendor release notes so your team knows what changes and when.
- Prepare systems, controls and evidence for your compliance assessments, while independent auditors issue any audit reports or certifications.
