Post

Did you know that if your organization is using #Microsoft365 / #office365 or #Azure then you are also ALREADY using the #Entra identity platform? Those services are built to use #EntraID as their identity provider (IDP), which is why identity based security controls can scale across them

3 reposts13 likes

Set this strategy at the leadership level if you want to be successful. Communicate this strategy to IT and the Business who are building and buying applications that all new applications integrate into #EntraID. This allows you to focus on your migration plan for existing and legacy apps

Presenting the user experience and security benefit to the business of integrating into the managed identity platform, that brings SSO, Passwordless, and takes away the need to manage it standalone is something to highlight. IT should be an enabler of the business to work securely, so showcase this

How do you get started? Well there are some great resources at aka.ms/migrateapps but my first recommendation is: πŸ₯‡ Set strategy to stop adding NEW Apps to legacy IDPs - For new apps, integrate it directly into #Entraid so you get all the benefits Day 1 for that app, don't need to migrate it later

aka.msResources for migrating apps to Microsoft Entra ID - Microsoft Entra IDResources to help you migrate application access and authentication to Microsoft Entra ID.

So if you want to consolidate your management of ALL applications and resources, you really want to move to that common control plane in #EntraID and not manage in multiple places. I have worked with many orgs to migrate their applications from traditional IDPs to the #entra identity platform.

So while you can choose to federate to 3rd party IDPs like #okta, #ADFS, #pingfederate, etc. They do not have the ability to manage granular access to services that are trusting #EntraID as their IDP. This is why most orgs who do this, still need to manage in both places to be effective.

A common point of confusion is with federated identity providers who focus on access to apps. If you have "office 365" in your federated IDP, what you really have is "Entra ID" as the application, and are also using #EntraID. So you end up having at least 2 IDPs to manage you chained together.

In the beginning days of those services it was common to use those services by federating your #entraID tenant to other IDPS, but in 2024 most organizations have moved away from that model and now managing it directly in #entra even if syncing users/groups/devices from onprem #activedirectory