Let's try going to and signing in with our user name and temporary access pass.

One-time usage will only allow the user to use it once, which may pose issues during the onboarding phase. Even if we are shown a password field, user will have no idea what to enter.īy clicking 'Add,' we can see the temporary access pass (just like an automatically generated password that only works for a limited time). When we sign in for the first time, our user does not know their password, so in order to make the first connection, we will need a temporary access pass, which is the only way for our user to login. This will require my user to sign in without a password. My policy is assigned to my test user, and I select my custom authentication strength under 'Grant' for all cloud apps. We now need to use our custom authentication strength in our conditional access policy that we created. Temporary Access Pass (One time use and Multi-use).At step 5, you will see the methods chosen: There is nothing dangerous about creating an new authentication strength.

To create a custom authentication strength, follow the steps below.

Remember to assign licenses, in my case I am creating the user in a developer tenant so its the M365 E5 Developer license.Ĭreate a custom authentication strength that only accepts passwordless authentication.

Ignore the field and let it auto-generate a password. When we go to to create a fresh user, the first thing we see is, predictably, 'password.' For some reason, it is necessary to give a password when creating a new user.

Conditional Access policy (assigned to our test user).

We'll put this to the test by accessing the Microsoft 365 portal. This blog post will take the necessary steps to allow only passwordless sign-in to our applications. To eliminate passwords completely, we must remove all surfaces and only accept passwordless sign-in to our cloud apps. Please beware of technologies in preview Disable password acceptance

Microsoft passwordless account