Let clients open shared SharePoint files with an emailed code – IT Solver Support

You can let clients open the files you share from SharePoint or OneDrive with only a code sent to their email. To do this, you change three sign-in settings for outside people in Microsoft 365. This article explains each setting in plain words, and shows where to select.

Simple sharing with clients

Many businesses send clients a link to their documents and limit the link to the client's email address. A link sent to the wrong person does not open. The client selects the link, enters a code from their inbox, and reads the file. It is quick for the client and safe for you.

Microsoft changed how this works, and for a good reason. When you share with an outside person, Microsoft now makes a small account for that person in your Microsoft 365. Your sign-in rules protect that account. An account with a second sign-in step is more secure than a code sent to a mailbox, because a person who gets into the mailbox cannot open the files.

This is part of a larger plan that Microsoft has published. Passkeys became the default sign-in on 1 September 2026. A passkey is a sign-in that stays on your phone or computer and uses your fingerprint, face or PIN, so there is no code that a criminal can trick you into giving away. Microsoft also stops its text message and phone call codes: on 1 February 2027 for most users, and on 1 July 2027 for Global Administrators and external users. Microsoft's reason is that text messages and phone calls are no longer safe enough.

The cost is friction. With the default settings, a client can be asked to sign in to Microsoft, make a password, or install an app on their phone before they can read one document. For a client who only wants to read their own file, that can stop them.

Each business must choose between the two. If easy access for clients is more important to you, the settings in this article give it back: a client again needs only their email address and a code. If your documents need the stronger protection, keep the Microsoft defaults and help clients through the first sign-in.

What your client does after the change

Opens the link in the sharing email.
Enters their email address.
Enters the code that Microsoft sends to that address.
Selects Accept on a permissions screen. This screen shows only on the first visit.

The client does not make a password and does not install an app. The link stays limited to the client's email address.

Step 2 is the weak point, and you cannot remove it. The link was sent to one address, but Microsoft's sign-in page does not fill that address in. It shows an empty box that asks for an email, phone or Skype name. The client must know to type the same address that received the link. A client with more than one email address can type the wrong one and get an error. This occurs for the emailed code too, where the address is the only thing Microsoft needs.

Tell clients this when you share: "Enter the email address that this message was sent to."

Two groups of clients do not get a code, because Microsoft controls this. A client whose email address is already a Microsoft 365 work account signs in with that account. A client whose address is a personal Microsoft account enters that account's password, unless you also do step 7.

Microsoft's words, in plain words

The Microsoft screens use many special words. You need these ones.

Tenant. Your organisation's Microsoft 365 as a whole: all its users, files and settings.
Microsoft Entra. The part of Microsoft 365 that holds user accounts and sign-in rules. Its old name was Azure Active Directory. You change the settings in the Microsoft Entra admin center, a website for administrators.
Guest. The small account that Microsoft makes in your tenant for an outside person when you share a file with them. You do not make it. It lets the person open only the things you shared.
Work account. A Microsoft 365 account that a person's employer gave them.
Personal Microsoft account. An account a person made for Outlook.com, Hotmail, Xbox or Skype. A person can also make one with a Gmail address, and then forget it.
MFA (multifactor authentication). A second sign-in step after the password. Usually it is a number from an authenticator app on a phone.
Conditional Access policy. A sign-in rule with three parts: which people, which apps, and what those people must do. For example: all users, all apps, must do MFA.
Email one-time passcode, or Email OTP. The code that Microsoft emails to a person, which the person types to sign in. It works one time.
Identity provider. The service that checks who a person is. For your clients there are three: their employer's Microsoft 365, their personal Microsoft account, or the emailed code.
Redemption. The first time a guest opens a shared link, Microsoft connects the guest account to one identity provider. Microsoft calls this "redeeming the invitation". After that, Microsoft remembers the choice, and the guest signs in the same way each time.
Redemption order. The list of identity providers that Microsoft tries, in order, at redemption. If an entry is off, Microsoft does not use it.
Reset redemption status. A button that makes a guest go through redemption again on their next visit. The guest keeps access to the files. Use it when you want an existing guest to change to the emailed code.
Dynamic group. A group that fills itself from a rule, for example "all guests". You do not add people by hand.

Scope and supported systems

Applies to: Microsoft 365 tenants that share SharePoint or OneDrive files with people outside the organisation, with Microsoft Entra ID P1 or higher. Entra ID P1 is included in Microsoft 365 Business Premium.

Why this happens

Several settings can cause the same symptom. Check the result after each step instead of assuming one cause.

A Conditional Access policy requires MFA for all users. Guests are users too, so each guest must set up an authenticator app in your tenant before the file opens.
The emailed code is off. Without it, a client who has no Microsoft account is told to make one with a password.
Microsoft selects the identity provider from the client's email address. You cannot select it for each share.

Microsoft checks the address in this order:

If the address has a Microsoft 365 work account, the client signs in with that account.
If the address is a personal Microsoft account, the client enters that account's password.
If Microsoft does not know the address, the client gets an emailed code. This occurs only when the emailed code is on.

Other administrators found the same order in their tests. See the r/sharepoint discussion about the change from the SharePoint code to Entra B2B. We refer to it in the sections below.

Before you start

You must sign in as an administrator. The Global Administrator role can do all the steps.
Understand the trade. You get less friction for clients, and you give up MFA for guests on SharePoint and OneDrive. The client's mailbox is then the only protection. A person who can read that mailbox can open the files shared to it. This is the same protection as the old SharePoint email code. If the documents are sensitive, make this decision with the business owner.
The steps do not change the sign-in for your staff or administrators.
Do not delete a guest and share again to test. That removes the guest's access to files you shared before.

Steps

Go to the Microsoft Entra admin center, https://entra.microsoft.com, and sign in. All the pages in the steps are in the left menu, under Entra ID.

Here is the plan. Steps 1 to 4 stop the MFA rule from applying to guests on SharePoint. Steps 5 and 6 turn on the emailed code. Step 7 is optional.

1. Find the rule that asks guests for MFA

What this does: you look at the record of one client's sign-in, to see which rule stopped them.

Select Users. Guests show the word Guest in the User type column. Open a guest who had the problem.
Select Sign-in logs. Open a line where the Application is Office 365 SharePoint Online.
Select the Conditional Access tab. Find the line that has Require multifactor authentication and the result Failure or Success. Write down its name.

In many tenants the name is Multifactor authentication for all users. Microsoft made this rule for you, and the list shows Microsoft next to it.

2. Make a new rule: guests need MFA on all apps but SharePoint

What this does: guests keep MFA on all other apps, for example Teams. Make this rule first, so that guests always have that protection.

Select Conditional Access > Policies > New policy, and give the rule a name.
Select Users > Select users and groups > Guest or external users. In the list, tick B2B collaboration guest users and Local guest users. These are Microsoft's names for the guests that sharing makes.
Select Target resources and choose All resources. Then select the Exclude tab > Select resources, search for Office 365, and tick Office 365 SharePoint Online. This entry covers OneDrive too.
Select Grant, tick Require multifactor authentication, and select Select.
At the bottom, set Enable policy to On and select Create.

3. Make a group that contains all guests

What this does: the rule from step 1 can leave out a group, but not a type of user. So you make a group that always contains all guests, also the ones you add later.

Select Groups > New group.
Set Group type to Security. Give the group a name, for example All guests.
Set Membership type to Dynamic User.
Select Add dynamic query. Above the Rule syntax box, select Edit and enter this rule: (user.userType -eq "Guest")
Select OK, Save, then Create.
Open the group after a few minutes. Continue when it shows its members.

4. Leave the guest group out of the all-users MFA rule

What this does: the rule from step 1 stops applying to guests. Your staff stay in it.

Select Conditional Access > Policies and open the rule from step 1.
Under Excluded identities, select Edit.
Tick the guest group, select Select, then Save.

5. Turn on the emailed code for guests

What this does: it lets Microsoft send a sign-in code by email. Microsoft calls this method Email OTP. It is off in many tenants.

Select Authentication methods > Policies > Email OTP.
Set Enable to on.
Next to Target, choose Select groups, select Add groups, and add the guest group from step 3. Do not choose All users: that also lets your staff reset their password with an emailed code.
Select the Configure tab. Set Allow external users to use email OTP to Enabled. "External users" is one more Microsoft name for guests.
Select Save.

6. Check that Microsoft will use the emailed code

What this does: you look at the redemption order, the list of sign-in methods that Microsoft tries for a new guest. The emailed code must be on in that list.

Select External Identities > Cross-tenant access settings.
Select the Default settings tab, then Edit inbound defaults. "Inbound" means people who come into your tenant from outside.
On the B2B collaboration tab, select Redemption order. "B2B collaboration" is Microsoft's name for work with guests.
Scroll down to Fallback identity providers. Make sure that Email one-time passcode shows Enabled.

This switch copies the setting from step 5. If you turn it on here before you do step 5, the page shows a success message, but the switch goes back to Disabled. That cost us time.

7. Optional: send codes to personal Microsoft accounts too

What this does: clients with a Hotmail or Outlook.com address, or an old Microsoft account on a Gmail address, also get a code and no password prompt.

On the same Redemption order page, turn off Microsoft Account (MSA) and select Save. The password and MFA of the client's Microsoft account then no longer protect the share.

This changes new guests only. A guest who signed in before keeps their old method, because Microsoft remembers the redemption. To change that guest, open them in Users and select Reset redemption status. They keep access to their files.

An administrator in the r/sharepoint discussion describes the same page and goes one step further: turn off all entries other than the emailed code, so that all guests get a code. We did not test that. It also removes the work account sign-in for clients who have Microsoft 365, and you must reset the redemption status of each guest who signed in a different way.

Check the result

Share a file with an email address that is not a work account and not a personal Microsoft account. A new free email address is a good test.
Wait 5 minutes.
Open the link from the sharing email in a private browser window. A private window makes sure that your own sign-in is not used.
Enter the email address. Microsoft sends a code to that address.
Enter the code, then select Accept on the permissions screen. This screen shows only one time.

The file or folder opens. The recipient does not see a password prompt or a request to install an authenticator app.

Tell your staff one thing: a client who opens the link in the first few minutes after you share it can see an error. The link works when the client tries again a few minutes later.

If it still is not working

An error with the code AADSTS90072 and the words "does not exist in tenant", immediately after you share: Microsoft has not finished making the guest account. Try the link again after 5 minutes. If the error text contains identity provider 'mail', the emailed code worked. Only the account was not ready.
The client gets a password prompt: the address is a work account or a personal Microsoft account. See the order in "Why this happens".
Your test address is on your own company's email domain: Microsoft sees a work account, so the result is not the same as for a client. Use an address that Microsoft does not know.
You are not sure how a guest signs in: open the guest in Users. Next to Sign-in identifiers, select View and read the Issuer column. mail is the emailed code, MicrosoftAccount is a personal Microsoft account, and ExternalAzureAD is a work account. If the page shows Invitation state: Pending acceptance, the guest has not opened a link.
The client must type their email address first: there is no setting that removes this step. We tested links from the sharing email and "Only people you choose" links, and each one showed the empty sign-in box. The client must type the address that the link was shared with.
Guests are still asked for MFA: do step 1 again with a new sign-in. A different rule applies to them.

What other administrators report

These points come from the r/sharepoint discussion. We did not test them, unless the text says so.

Old Microsoft accounts on Gmail addresses. A person who used a Gmail address with a Microsoft service years ago can have a Microsoft account and not know it. That person gets a password prompt and no code. Our test with a Gmail address gave the same result. Step 7 removes this problem for new guests.
MFA from a personal account is not accepted. When a rule requires MFA for guests, administrators report that guests with a Gmail address or a personal Microsoft account must set up an authenticator app in the host tenant. We saw the same before step 4.
Trust MFA from other Microsoft 365 tenants. If you keep MFA for guests, there is a setting on the Trust settings tab of Edit inbound defaults. It lets a guest with a work account use the MFA of their own organisation. It does not help clients who have no work account.
Authentication strengths. One administrator reports that a rule for guests can use only the standard Require multifactor authentication control, and not a custom list of permitted methods.
More guest accounts. Each share with a new person now makes a guest account in your tenant. Plan a regular review of guests who do not sign in. One administrator recommends that you block old guests and do not delete them, because a deleted guest who comes back with the same address can have problems on SharePoint sites.
The security argument. Some administrators in the discussion keep MFA for all guests, because a guest's mailbox can be compromised. Read their reasons before you remove MFA for guests.

Official sources

Community discussion

r/sharepoint: the SharePoint email code to Entra B2B transition

Last verified: 2026-11-12

Need help?

If the steps above did not solve the problem, see IT Solver support options.