Quick answer. As of September 2026, connecting an application to Microsoft Entra ID means choosing the sign-in method that application supports (Microsoft says to choose OpenID Connect and OAuth where the application supports them, SAML for existing applications that do not, and password-based sign-on for applications with only an HTML sign-in page), then deciding whether Entra ID will also provision the application’s accounts and which Conditional Access policy covers it. Start with the applications that already speak SAML or OpenID Connect, which Microsoft’s migration guidance says to move first, and test in a non-production environment before production. Every integration leaves your team owning something, at minimum an application object or enterprise application, and for SAML a signing certificate that, according to Microsoft, is valid for three years by default, so name the owner before go-live.
A single sign-on program rarely stalls on the first gallery application. It stalls on the application nobody owns, whose vendor has never heard of SCIM, and whose signing certificate will expire with no one named to renew it. This page is for the IT leader who has Microsoft 365 on Entra ID already and now has to bring the rest of the estate, from SaaS subscriptions to applications built in-house, under the same sign-in. Every Microsoft page cited here was read on September 23, 2026.
Sort the Estate by How Each Application Signs In Today
Before any application moves, the decision that sets the work for each one is how it authenticates now. Microsoft’s What is single sign-on in Microsoft Entra ID? page says “The right SSO method depends on how an app authenticates and where it runs.”
Microsoft’s Plan a single sign-on deployment page gives the options by where the application runs: “Cloud applications can use OpenID Connect, OAuth, SAML, password-based, or linked for SSO. Single sign-on can also be disabled.” The same page gives its rules for choosing: “Choose OpenID Connect and OAuth 2.0 if the application you’re connecting to supports it.” “Choose SAML whenever possible for existing applications that don’t use OpenID Connect or OAuth.” “Choose password-based when the application has an HTML sign-in page. Password-based SSO is also known as password vaulting.”
Where the application came from decides how it is registered. Microsoft’s What is application management in Microsoft Entra ID? page says “The easiest way to start managing an application is to use a preintegrated application from the Microsoft Entra gallery.” and “Each application in the Microsoft Entra gallery has an article available that shows you the steps required to configure the application.” For applications your organization built or bought as a packaged product, Microsoft’s Understand the stages of migrating application authentication from AD FS to Microsoft Entra ID page says “Line-of-business apps that use OAuth 2.0, OpenID Connect, or WS-Federation can be integrated with Microsoft Entra ID as app registrations. Integrate custom apps that use SAML 2.0 or WS-Federation as non-gallery applications on the enterprise applications page in the Microsoft Entra admin center.”
The sorting table i3solutions uses, built from those Microsoft categories, is filled in once per application:
| The application | The integration Microsoft describes | What to record for it |
|---|---|---|
| A SaaS application listed in the Microsoft Entra gallery | A gallery enterprise application, configured from that application’s own article | The article followed, and whether a provisioning connector exists |
| A line-of-business application that uses OAuth, OpenID Connect or WS-Federation | An app registration | Who owns the registration |
| A custom application that uses SAML or WS-Federation | A non-gallery enterprise application | The signing certificate and who renews it |
| An application with only an HTML sign-in page | Password-based sign-on, also known as password vaulting | Who holds the shared account and whether the vendor plans federation |
| An on-premises application that uses Integrated Windows Authentication or header-based sign-in | Application Proxy with one of the on-premises options | The license line below, and the bridging decision |
| An application not ready to integrate | Disabled, or linked while you migrate | The date it gets a real integration |
Linked and disabled are states, not integrations. Microsoft’s Plan a single sign-on deployment page says “The Linked option doesn’t provide sign-on functionality through Microsoft Entra credentials.” and “Choose disabled SSO when the application isn’t ready to be configured for SSO.” Its What is single sign-on page adds “Linked SSO keeps a consistent experience while you migrate apps. It adds app links in user portals, but it doesn’t provide true single sign-on.” An application left linked still signs in through its own sign-in or another identity provider, not with Microsoft Entra credentials.
On-premises applications are their own bucket. Microsoft’s Plan a single sign-on deployment page says “On-premises applications can use password-based, Integrated Windows Authentication, header-based, or linked for SSO. The on-premises choices work when applications are configured for Application Proxy.” Choosing how to bridge applications that use Kerberos or header-based sign-in is a separate decision from this sequence, and why the size of that bucket matters to the platform choice is covered in Which IAM Platforms Fit a Complex Hybrid Enterprise: How to Decide.
Which Applications Go First
When every application owner wants to be next, the order needs a rule the IT leader can defend. Microsoft’s Understand the stages of migrating application authentication from AD FS to Microsoft Entra ID page gives the first cut: “When you plan your migration to Microsoft Entra ID, consider migrating the apps that use modern authentication protocols (such as SAML and OpenID Connect) first.” It also says “We recommend that you continue to use existing test environments for migration testing before you move to the production environment.”
Microsoft’s Plan application migration to Microsoft Entra ID page says “The process is broken into four phases.” It names them Discover and Scope, Classify apps and plan pilot, Plan migration and testing, and Manage and gain insights. The same page says “Application migration is a team effort”, and its role table includes a project manager, an identity architect, application technical owners, application business owners and a pilot group of users.
Applications still federated through AD FS can be sorted by Microsoft’s own tooling. Microsoft’s AD FS application migration to move AD FS apps to Microsoft Entra ID page says “The wizard gives you a unified experience to discover, evaluate, and configure new Microsoft Entra application.” It marks each relying-party application with one of three statuses: “Ready to migrate means, the AD FS application configuration is fully supported in Microsoft Entra ID and can be migrated as-is.”, Needs review, where some settings need review but are not blockers, and “Additional steps required means, Microsoft Entra ID doesn’t support some of the application’s settings, so the application can’t be migrated in its current state.” Moving Microsoft 365 sign-in itself off AD FS, and retiring the farm, is a separate decision from moving its applications.
The sequencing rule i3solutions recommends on top of Microsoft’s guidance:
- Rank each application on audit and business exposure: in scope for your framework, holds regulated data, or used by privileged or external users.
- Rank it again on integration effort: a gallery article and provisioning connector, a custom registration, password-based sign-on, or no modern protocol.
- Start with high-exposure, low-effort applications, so the audited systems move early without the hardest integrations setting the pace.
- Pilot each wave with IT and the application’s business owner in a test environment before widening it.
What Each Integration Leaves You Owning
An integration that works on go-live day can fail years later if nobody knows what was created. Microsoft’s Application and service principal objects in Microsoft Entra ID page says “To delegate identity and access management functions to Microsoft Entra ID, an application must be registered with a Microsoft Entra tenant.” It describes the two objects that registration creates: “An application object is used as a template or blueprint to create one or more service principal objects.” and “A service principal is created in every tenant where the application is used.” It adds “The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.” and “You can use the Enterprise applications page in the Microsoft Entra admin center to list and manage the service principals in a tenant.”
SAML applications add a certificate with an expiry date. Microsoft’s Plan a single sign-on deployment page says “When you enable federation on SAML application, Microsoft Entra ID creates a certificate that is by default valid for three years.” and tells you to have “processes in place to renew certificates before their expiration”. Microsoft’s Enable SAML single sign-on for an enterprise application page walks through the work for one application: entering the application’s Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL) in Entra ID, downloading the SAML signing certificate, and adding those configuration values in the application itself. It says “We recommend that you use a nonproduction environment to test the steps in this article.”
Administrative roles are part of the design. The Plan a single sign-on deployment page says “Always use the role with the fewest permissions available to accomplish the required task within Microsoft Entra ID.” Its persona table lists Cloud Application Administrator as the Microsoft Entra role for the identity admin and for the certificate rollover owner.
The ownership rule i3solutions recommends: every application enters with a named technical owner, a named business owner and a named certificate renewal owner, recorded before go-live. Governing the credentials, secrets and owners of application identities across the whole tenant is a program of its own beyond this onboarding sequence, and Governing Non-Human Identities in Microsoft Entra: Service Principals, App Registrations, Managed Identities, Secrets, and AI Agents With Entra Agent ID sets that program out, including how an app registration differs from a service principal.
Sign-In Is Not the Account: The Provisioning Decision per Application
If an application gets single sign-on but not provisioning, the leaver still has an account in it until someone removes it by hand. Microsoft’s What is app provisioning in Microsoft Entra ID? page says “Microsoft Entra application provisioning refers to automatically creating user identities and roles in the applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change.”
Whether that is available depends on the application. The same page says “The preintegrated applications listed in the gallery generally use SCIM 2.0-based user management APIs for provisioning.” and “Manual provisioning means there’s no automatic Microsoft Entra provisioning connector for the app yet.” It also says “Microsoft Entra ID also supports provisioning users into applications hosted on-premises or in a virtual machine, without having to open up any firewalls.” For an application still to be bought, Microsoft’s condition for adding an application’s provisioning connector to the gallery is a procurement question: “For a user provisioning request, we require the application to have a SCIM-compliant endpoint.”
Microsoft’s Plan an automatic user provisioning deployment in Microsoft Entra ID page says “We recommend that the initial configuration of automatic user provisioning is in a test environment with a small subset of users before scaling it to all users in production.” and “Use scoping filters to define attribute-based rules that determine which users are provisioned to an application.” Application licenses follow the same accounts; the Plan a single sign-on deployment page says “If Microsoft Entra ID manages the automatic provisioning based on roles, the roles assigned in Microsoft Entra ID must align with the number of licenses owned within the application.”
For each application, record one of two outcomes: a provisioning connector planned, or manual removal accepted as a known gap with a named person who performs it. One application’s sign-in and provisioning worked through end to end is in ServiceNow and Microsoft 365 Integration: Four Paths, and What Each Does to Your Governance Boundary. Once accounts flow, who should hold access is governance, covered in Microsoft Entra ID Governance for Regulated Enterprises: Product Scope, Licensing, and Audit-Defensible Implementation.
Conditional Access Coverage: Which Applications a Policy Reaches
When an application is newly integrated, it is protected only by the Conditional Access policies that target it. Microsoft’s Conditional Access: Target resources page says “Conditional Access policies let admins assign controls to specific applications, services, actions, or authentication context.”
Not every application can be picked by name. The same page says “Some applications don’t appear in the picker at all.” For those applications, Microsoft names two routes: include the All resources option in the policy, or add the missing service principal. It also says “Microsoft recommends creating a baseline multifactor authentication policy targeting all users and all resources (without any resource exclusions)”.
The coverage rule i3solutions recommends: a newly integrated application goes under the all-resources baseline policy on its first day, and any policy written for one application is designed and tested before that application’s wave.
The License Lines to Check Before the Plan Depends on Them
When the plan assumes a capability the tenant is not licensed for, the gap shows up mid-wave. Microsoft’s Plan a single sign-on deployment page says “SSO for preintegrated enterprise applications is free. However, the number of objects in your directory and the features you wish to deploy might require more licenses.”
Microsoft’s Microsoft Entra licensing page, as read on September 23, 2026, marks Conditional Access under Microsoft Entra ID P1 and P2, and risk-based Conditional Access under P2 only. In Microsoft’s provisioning rows on that page, automated user provisioning to SaaS apps is marked under Free, Microsoft Entra ID P1, Microsoft Entra ID P2, Microsoft Entra ID Governance and Microsoft Entra Suite, and automated provisioning to on-premises apps under the same columns except Free. The same page says “Microsoft Entra application proxy requires Microsoft Entra ID P1 or P2 licenses.”
Application licenses are a separate line. The Plan a single sign-on deployment page says to “Work with the application owner to determine whether the users assigned to the application have the appropriate licenses for their roles within the application.”
When This Plan Is the Wrong Move
If one of these situations is yours, a different step comes first:
- If your applications sign in through Okta today, this is a migration with its own coexistence and rollback plan; see How Do I Hire Consultants to Migrate Us Off Okta Onto Microsoft Entra ID Without Breaking Access?
- If Microsoft 365 itself still signs in through AD FS, settle that sign-in model before sequencing the applications behind it.
- If most of the estate uses Kerberos or header-based sign-in and nobody may change those applications, the bridging pattern is the decision, not the sign-in protocol.
- If an application has a handful of users, holds no regulated data and sits outside audit scope, leaving it on local sign-in or a linked tile for now is a defensible choice, recorded as one.
- If a vendor supports neither SAML nor OpenID Connect nor SCIM, password-based sign-on (for an application with an HTML sign-in page) is the sign-in option, and unless the application offers another interface Microsoft’s provisioning page lists, such as an LDAP directory, a SQL database, or a REST or SOAP interface, a recorded manual removal process is the honest provisioning option until the vendor changes; do not describe an application on manual removal as covered by provisioning.
Who Owns the Application Catalog After Go-Live
New applications keep arriving, certificates expire and owners leave, so the catalog needs an owner named before the last wave closes. Name who approves new applications; Microsoft’s Overview of user and admin consent page says “The admin consent workflow gives users a way to request admin consent for applications when they aren’t allowed to consent themselves.” The wider consent and permission review is covered in Microsoft 365 Access Governance for AI Readiness. Name who renews certificates and who reviews assignments: the internal identity team, or an outside provider working to your schedule.
An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in. What i3solutions does in place of running a help desk is set out in We Do Not Run Your Help Desk. Here Is What i3solutions Does Instead.
How i3solutions Approaches It
If the estate needs outside help, the work is a project: the estate sort, the sequence, the per-application integration design and build covering sign-in, provisioning and Conditional Access coverage, and the ownership runbook, handed to the owner you name.
i3solutions is a Microsoft Systems Integrator with experience implementing identity and access management solutions for enterprises in regulated industries. On Entra ID specifically, i3solutions delivered an Entra ID integration engagement for a global consumer goods manufacturer. Beyond that engagement, i3solutions regularly delivers Okta to Microsoft Entra ID migrations for enterprises. i3solutions has done hundreds of Okta to Entra ID conversions. On provisioning, i3solutions unified identity and automated provisioning across systems for 125,000 users by treating the interfaces as owned, governed contracts. Delivery is senior and US-based.
The service line is described in Enterprise Entra ID Configuration & Integration Services for Modern Identity Management, within Establish Identity as a Governed Enterprise Capability.
Key Takeaways
- Choose each application’s integration from how it signs in: OpenID Connect or OAuth where supported, SAML for existing applications that cannot, and password-based sign-on for an HTML sign-in page, per Microsoft.
- Linked and disabled are interim states; an application left linked still does not sign in with Microsoft Entra credentials.
- Move the applications that already speak SAML or OpenID Connect first, as Microsoft’s migration guidance says, and test before production.
- Every integration leaves an application object or service principal, and SAML adds a signing certificate valid for three years by default, according to Microsoft; name the owners before go-live.
- Single sign-on does not remove a leaver’s account; decide provisioning per application, and put every new application under an all-resources Conditional Access baseline.
Frequently Asked Questions
Should we use SAML or OpenID Connect for an application in Entra ID?
Use OpenID Connect where the application supports it. Microsoft says “Choose OpenID Connect and OAuth 2.0 if the application you’re connecting to supports it.” and “Choose SAML whenever possible for existing applications that don’t use OpenID Connect or OAuth.”
What is the difference between an app registration and an enterprise application?
The app registration creates the application object, and the enterprise application is the service principal in a tenant. Microsoft says “An application object is used as a template or blueprint to create one or more service principal objects.”, “A service principal is created in every tenant where the application is used.” and “You can use the Enterprise applications page in the Microsoft Entra admin center to list and manage the service principals in a tenant.”
Is single sign-on to gallery applications free in Entra ID?
Yes, with a caveat. Microsoft says “SSO for preintegrated enterprise applications is free. However, the number of objects in your directory and the features you wish to deploy might require more licenses.”
Does SSO also create and remove user accounts in the application?
No, that is provisioning, a separate decision. Microsoft says automatic provisioning “includes the maintenance and removal of user identities as status or roles change.” and “Manual provisioning means there’s no automatic Microsoft Entra provisioning connector for the app yet.”
Which applications should we move to Entra ID first?
Start with the applications that already use modern protocols. Microsoft’s guidance is to “consider migrating the apps that use modern authentication protocols (such as SAML and OpenID Connect) first.” Within that group, i3solutions recommends starting with the applications that carry the most audit and business exposure for the least integration effort.
Does Conditional Access require a paid Entra ID license?
Yes. According to Microsoft’s licensing page, as read on September 23, 2026, Conditional Access is marked under Microsoft Entra ID P1 and P2, and risk-based Conditional Access under P2 only.
Scoping the Application Integration Plan
If your team needs the application estate sorted, the sequence set and each integration designed with its provisioning and Conditional Access coverage, the next step is a conversation about your applications, how each one signs in today and what your auditors will ask to see.
