Guest Users : Federation Applications Access

This is a walkthrough on how to get External users working via Federated applications and the cavets and pitfalls you can get along the way.

If you have guest users and you wish them to use your Federated Applications then this can be completed with the "guest account" option in Entra, so first lets get the user invited:

We then need to create the user, as below, notice the option for "Send invite Link" this is important later on:

This will send you a link that you need to accept in order to use this account you will need to click on the link or visit the URL to use this account, it is NOT active by default, more on that next:

What if you do not accept the invite?

If you try to login without accepting the invite then this will end in disaster, using the address from earlier lets try that now and not follow the instructions:

This does not work as there is no Microsoft account for that user, which means for this to work you also need a Microsoft account to authenticate with, its not magic.

Accepting the Invite

This time lets accept the invite and use the link in the email, first I went though a phase of these errors which is not very fluid at all but then soon released this was the old link so this means the link is not correct:

When we use the correct link if that account is not link to a Microsoft you will then need to signup for one as below, in this case this is a "personal" account:

You will then need to complete a MFA to prevent fraud:

Then we need some more details:

Then we need to prove we are human by pressing and hold a button, weird one Microsoft?

The we need to do MFA, and no I do not skip this, it should be standard in 2025 to always have MFA, plus I have a policy that requires this, so this will fail later on:

Now my tenant permissions kick in and you can see my tenant needs permissions to your account, here you need Accept:

This is where my MFA policy kicks in and requires you have have MFA from my tenant options, this is not optional:

MFA Methods Unavailable?

However we then get this, which is a problem indeed, this says my tenant is not allowing any authentication methods - but why?

They are enabled as you can see here, and this tenant has completed the migration to "Conditional Access" based policies:

Diagnosing “ No authentication methods”

This is not good I think I have set the "Guest User access" collaboration settings to secure with this option:

Therefore I will update that settings to not the most restrictive:

This seemed to make no difference to my MFA options missing, there is some logic about this being Tenant restrictions set to "All Blocked" - but this makes no sense from a technical point of view, this is set from the External Identities > Cross-tenant access settings but this was also not the problem:

Those settings were updated to the original settings As they were only changed for diagnostic purposes.

In this scenario the issue for me was this migration, when set to "complete" is uses Conditional Access to read the options and policy settings:

This is outlined here, but in my scenario I need "Migration in progress" for the reason below: 

This is the problem I seem to have no Conditional Access license and "complete" options requires a P2 license:

If you try to edit a conditional access policy you get can error about not having a Entra ID P2 license:

This means I need to get this changed from "complete" to "in progress" as below:

After this is changed I now get the option to use Authenticator:

The however is not the cause of the problem, this  setting will automatically change in November 2025, so leaving it like that is a bad idea, the more technical cause of the problem stems from the fact, I have conditional access policies, but I’m not licensed to use them - so in this particular scenario we have a couple of options:

1. You already have an Entra ID P1/P2 license
2. Purchase Entra ID P1/P2 license
3. Reject the Entra ID P1/P2 license (which will require mandatory use of security defaults)

Licensed or Purchased License

This option only applies. It’s already have the devices or you’re looking to purchase it - if you are going to be licensed or already are, I would highly recommend a dedicated condition policy to cover external users.

1. Create the Conditional Access Policy

Navigate to Entra ID > Security > Conditional Access > New Policy

Basic Settings:

• Name: "External Users - Authentication Requirements"
• State: Enabled

2. Configure User Assignments

Users and Groups:

• Include: Select "Guest or external users" → "B2B collaboration guest users"
• Exclude: None

Cloud Apps:

• Include: All cloud apps (or specific applications as needed)

Conditions:

• Device platforms: Not configured (allows all platforms)
• Locations: Not configured or exclude trusted locations
• Client apps: Modern authentication clients

3. Set Access Controls

Grant Controls:

• Grant access
• Require multifactor authentication
• For multiple controls: Require one of the selected controls

Session Controls:

• Sign-in frequency: 1 day (optional - forces periodic re-authentication)
• Persistent browser session: Never persistent

4. Configure Cross-Tenant Access Settings

This is the crucial step that many administrators miss!

Navigate to Entra ID > External Identities > Cross-tenant access settings > Default settings

Inbound Access Settings:

• B2B collaboration:
  • Users and groups: Allow all
  • Applications: Allow all

Trust Settings:

• Trust multifactor authentication from Azure AD tenants

Authentication Methods: Allow external users to use:

• Microsoft Authenticator
• FIDO2 security keys

No license/Rejected License

⚠️ WARNING: This blog does NOT advise deleting conditional access policies. Ensure you have NO Azure AD Premium license and as you will find out later on in this post Entra ID P1 is required!!!!

If you do not have a license, but back before the licensing rules changed, you already have conditional access policy set up that are disabled - this will indeed cause this error and there is only one way to fix this by deleting all the disabled active conditional access policies..

When do you have successfully deleted all your conditional access policies you will notice that you can now configure security defaults - this is the only option you have to keep your tenant secure if you’re not going to purchase a license, if you try to set security defaults at the moment your will be blocked:

When all your policies are all deleted the Conditional Polices policy list will look like this, empty:

Then if you navigate to Entra > Properties you will notice that the security default is now available to update:

Then when you manage the security defaults update it from being disabled to enabled, the default is disabled after this update.

You will then get an error to say "Identity Protection" is enabled so you cannot use security defaults, so you now need to go to to Entra > Security > Identity Protection and disable each one of these options:

You need to set these to "Disabled" as these also require a Entra ID P1/P2 license and wait a moment for Entra to catch up:

Then when you now try to update the security defaults you will now be allowed to the update the setting:

Finally we are now on the correct security defaults:

Now we have climbed out that rabbit hole we can get back on track with the setup, however we have fallen back in the rabbit hole of no authentication available with the "migration" set to enabled:

After looking at this a little more it would appear you actually need a Entra ID P1 licenses to allow these settings to work, without these settings after the migration end date Azure AD Premium licenses are required to configure the cross-tenant trust settings that are essential for external user authentication to work properly.

Microsoft have forced people with labs and test environments to acquire a Entra P1/P2 license, none negotiable!

Back on Track : Continue the account setup

Right, now are back to this stage we got to pre-rabbit hole:



I have decided to use for this test a SMS version of this:

If you prefer the legacy SMS messages remember that the initial Verification code will appear via your legacy SMS channel - however, future messages will appear if you have a WhatsApp account via WhatsApp - this is to prevent SMS fraud because SMS is not particularly secure anymore.

When we complete that verification you can now see that MFA in the security section, so we are now setup with MFA:

We can now confirm the guest account we created earlier now has a Microsoft account and we now have that account active in the target tenant as below in the green box:

We now have a valid account that as you can see in Entra is now active with valid identities:

Using the Guest Account with the Federated Application

Finally, we have a accepted guest account all ready to use the Federated application, so we now need the iDP (user initiated) or SP (server initiated) address to try that external login, this is that URL:

This is my Twingate that uses Azure AD as a ODIC login, but the process is the same for SAML as well, so lets click that login button and use the external account:

In this example we then need MFA for Twingate as per policy:

Then when this is done we can confirm that the login is all good as we need the client:

Success, we have shown that an external can login via Federated application on a Guest account, however they need to accept the invite and they need a Microsoft account (or some form) - even though it was more complex that I first thought with the sneaky Entra ID license requirement.