We’ve heard from you that interconnected supply and distribution chains, and vendor models are bringing B2B partners directly into your business, where secure and seamless collaboration is more important than ever. We also know how painful it can be for IT managers to keep track of guest user accounts, and for end users to remember multiple usernames and passwords. We are continually improving our Azure AD External Identities solution with more support for bring-your-own-identity (BYOI) options.
Today, we are announcing another enhancement to our BYOI story with the general availability of email-based one-time passcode (email OTP) feature for collaboration.
With email OTP, org members can collaborate with anyone in the world by simply sharing a link or sending an invitation via email. Invited users prove their identity by using a verification code sent to their email account. Once authenticated, each session providing access to the shared resource lasts 24 hours. On subsequent sign ins, users receive a new one-time code via email, which they must enter to prove continued ownership of the email account and continue receiving access.
Azure AD treats email OTP-based users like other B2B guests, making them subject to security policies set by your organization such as Conditional Access, Multi-Factor Authentication (MFA) and periodic access reviews.
Alex Simons (@Alex_A_Simons)
Corporate Vice President of Program Management
Microsoft Identity Division
Learn more about Microsoft identity:
How does this apply to Teams, SharePoint, and OneDrive? If I invite someone to a Team, or share a single file or folder in SharePoint with someone, how do they get back to that Team or item that was shared with them? Do they have to keep the email invitation forever and always start at that email to get back to the content that was shared with them?
Is this still restricted/constrained by the AzureAD External Collaboration settings, so if one is using the Allowed Domains list, invites can still only be sent to those domains?
What does the error look like if you attempt to send an invite to a domain not on the Allowed Domains list, or if you do not have Invite permissions?
How does this apply to Azure Government or GCC-High tenants?
© Microsoft. This article was originally published by Microsoft Azure Active Directory Identity Blog. You can find the original article here.