At Ignite we announced a major improvement to the way secure external sharing of files and folders works in both OneDrive and SharePoint in Office 365 and we wanted to share what this means for users and IT administrators alike. Based on your feedback, we have focused our updates on two key areas:ensuring intended recipients get access 100% of the time, and continual reverification of identity.

These updates will begin rolling out to First Release tenants on October 9, 2017.

Office 365 makes it easy to share files and folders by creating a shareable link. Recipients can click the link and immediately access the file without having to go through any additional process. You can already create links that can be used by anyone, and links that are internally shareable within people in your organization.

Sometimes you need to share with additional security and require that people with the link prove that they are intended recipients. Office 365 also makes it easy to do this by allowing you to send links that work only for specific people

Now, when sending secure links to recipients outside of your organization, those recipients will be sent an email message with a time-limited, single-use verification code when they open the link. By entering the verification code, the user proves ownership of the email account to which the secure link was sent.

Secure links allow external recipients to access files and folders securely without requiring them to create or maintain a Microsoft account. Email-based verification codes are a simple and effective way to provide secure access, familiar to users who access secure internet sites that verify identity by sending a code by email or text message.

Continual reverification of identity

Now, IT administrators can specify how often external recipients must get a new code and re-verify their email address. This governance control protects your organization’s files and folders from situations where an external recipient’s employment status changes, or any other situation which can cause them to lose access to their email account.

To enable this setting, go to the sharing section in the SharePoint admin center.

IT professionals will recognize secure links provide access to external recipients using the same standard adopted by many financial institutions: email-based verification codes and reverification periods. This familiar approach is easier to manage and more secure than competing solutions that require an external recipient to create user accounts that may persist even after the user leaves their current employer and no longer owns that email, creating a very dangerous security hole.

Getting started

These features start rolling out on October 9, 2017, to First Release customers and will roll out to all customers by the end of January 2018.

But if I shared a file (and made it editable) to an external user, if they have no Microsoft Account, they can't edit it online I correct? I thought MS stated last month that you could share with external users and they did not need a login. It would send a "code" to their email and that's all they needed. I suppose they would need Word, etc. online to make use of this though right?

From MS below:

If your OneDrive and SharePoint Online external sharing settings are set to allow sharing with new external users, new external users (that have a file or folder securely shared with them) will be able to access the content without needing an Office 365 account or a Microsoft account. Instead, recipients who are outside of your organization will be sent an email message with a time-limited, single-use verification code when they access the file or folder. By entering the verification code, the user proves ownership of the email account to which the secure link was sent. Securely sharing a file or folder is the process of sharing in a way where recipients must prove that they're intended recipients that the original sharer specified. End-users can do this in the same way that they already do. (by changing the link settings to only work for specific people in the Share dialog) We're also introducing a new admin control which will allow you to specify how often external recipients must re-verify their email address and enter a new code. This protects your organization from cases where an external recipient’s employment status changes.

@Mark Uvanni when you share a document (with an edit link) with an external user who doesn't have a Microsoft account, they will be able to edit it in Office Online 100% of the time. There is no requirement on the recipient beyond having a working browser and an Internet connection.

This is true for both links that work for anyone and links that work for specific people. For the latter, the recipient will receive a one-time code at their email address to verify that they are the intended recipient.

These updates will begin rolling out to First Release tenants on October 9, 2017. Then to standard tenants after that. It can take 30-90 days for features to show up once released so expect between Nov and Jan for non-First Release customers.

@Paul Turner, the link actually knows what email addresses are and aren't valid. So if I share with Eugene@contoso.com and he forwards the link to you, there verification code will go to Eugene still, not your email. Hope that helps!

So if I have received both the link and the code, validated my email address using the code I have continuous access to that resource until I need to validate my email address again? How is access to others prevented if the link is still forwarded?

@Paul Turner, if the link is forwarded, it will act just like if you attempted to open the link on a new computer: it will send you another verification code and ask you to verify your identity again. The link will not let anyone other than the users with whom the link was originally shared with access the document.

@Benjamin Niaulin This replaces the recipient experience when securely sharing files and folders with new users outside of your organization. When you share to an existing user that exists in your organization's directory then they do not go through this experience.

I'm really afraid of this change. I've noticed this feature in an Ignite session and it sounded great. But as @Benjamin Niaulin I've got confused about the implementation. If this is replacing the current option this will be a major step back for all users receiving an invitation having an AAD account. In the "past" this was a great experience and in my opinion super secure. Now you replace this feature with a less secure method. For example:

In Tenant Contoso I create a O365 Group and allow external email communication (fake.marco.scheel@contoso.onmicrosoft.com). On Tenant Fabrikam a user wants to share with Contoso. So I give the Fabrikam user my fake email address and I will receive all communication in the O365 Group and now everyone with access to the group at Contoso can access the shared files/folder in the Fabrikam tenant. Even without a group I could easily share the "account" with my colleagues if I forward the PIN to the other user. The current system is not bullet proof, but we have a lot of control. We have customers that apply conditional access to all #EXT# users to enforce additional Microsoft MFA to access tenant content.

Yes all of this is still solvable with a proper custom Azure AD B2B collaboration solution, but this is not a OOB solution. Any chance to postpone this change? It solved the problem of people not getting the Invite Redeem model (current version). I didn't see any uproar on twitter or blogs so far. Not sure if I'm the only one, but I think this is a pretty dramatic change. I'm open to any calls or discussions you want/should start :)

@Marco Scheel if I understand correctly, the scenario you’re describing is one where a user at Fabrikam wants to securely share with a user in Contoso, but the user in Contoso maliciously deceives the user in Fabrikam and gives them an email address that belongs to a group or distribution list. Now, the link that gets sent to that email address will work for everyone in the group (since each of them can grab the latest single-use passcode that is sent to the group/DL).

That’s correct. We assume that the inhibition threshold is much lower to forward the PIN in the new scenario vs. giving someone the password of their own account. Even then if the account is protected using MFA the scenario is even harder to share “credentials” with other users.

With the current process users in SharePoint can easily invite external users and after the redeem process the external account is available in the AAD as a user of type “guest”. Having a AAD reference enables all the benefits of the introduced B2B collaboration features like additional MFA and AAD based group membership.

Yes there is the option to add external guests to Office 365 group, but in most cases this is not the scenario my customers are looking for. Most scenarios only share specific folders with external users.

With the new model you are mixing models and I think this is not easier to understand for users. One user already available in the AAD (because he was added to Office 365 Group as a guest) will not use the PIN based login while another user accessing the same file/folder is using the PIN method because the user was not yet added to the AAD.

So surely a combination of the username and PWD along with the one time pin covers off the scenario of somebody leaving the original organisation? Its not really friction free but allows the source tenant admin the ability to remove the user as they are AAD, but they need to be able to receive the PIN

Has the verification code external sharing option been fully released to First Release customer yet. It states it will be rolled out to First Release Customers in October and all customers by the end of the year. We are Frist Release and looking forward to getting access to this feature but still do not have access to it today. We have external sharing for new and existing external users allowed in One Drive and SharePoint but the option for the Verification code is not available and external uses are prompted for a Microsoft account with no option to request an access code. Am I missing something? How do we get access to this. Thank you.

Hey @Ed Kelly, I believe @Stephen Rose said 60-90 days from when it begins to roll out to First Release tenants, which was scheduled to start on Oct 9th. 60 days would be about December 11th; 90 days would be Jan 8th for rollout for non-first release. Just doing the math I'm going to guess that first release should expect it on or before Dec 11th (one month from now).

So it is happening on my lab tenants (FR for all users). So now lets have a look at this disaster. Still not convinced this is a suitable replacement for the current sharing (creating a Azure AD guest user). Not saying we can get used to it, but the current situation was "under control". But lets wait and see. I will du a write up to gather the full impact for my clients.

Anyone else have this experience? Trying to document for the new sharing experience. In the new setup sharing a link works fine. External user can access but it seems that the "sharer" can't "Remove Link". The Remove Link wizard gives warning but doesn't remove the link. Even an Sharepoint admin can't. The Advanced > Remove link under Manage Links is grayed out? I can just delete the shared folder, but removing the link does nothing?

Organizations that are opted into First Release for all users should now have this feature!

@BRETT COX in the OneDrive or SharePoint admin center you have the ability to change external sharing settings. This feature is enabled when your settings allow sharing to new external users.

@Rudi Schmitz In your first screenshot (the one with the orange icon) what happens when you click on the "x" ? That should bring up a dialog like the one below. Once you click "Remove link" the link will be deleted and will stop working for people who have it.

The second screenshot is actually showing a direct (or 'canonical') link to the file. If you grab that link you should see it is not the same link as the one you previously created. This direct/canonical link is the same type of link that you get when you share to "people with existing access" (so not really sharing in the sense that the link does not grant any new permissions). We'll look into the wording as I agree it can be confusing that it uses the term "specific people".

The feature will apply to all tenants but you can control external sharing on a per site collection basis using existing controls. Sites that don't have external sharing behavior won't allow this type of external sharing either. Thanks!

-> Share only a folder to User X and a random hotmail/email address (basically a account not yet a guest user in Tenant 1 AAD, so the new sharing capabilities will be used)

--> In this case the User X receives to mails

---> Email 1 is a normal B2B sharing link

---> Email 2 is a new secure sharing link as described in this post above

At the moment both links are working. But during testing right after the user was invited and accepted to the AAD of Tenant 1 (as guest account) both email resulted in an error (Email 1 aka B2B: Access Denied | Email 2 aka Secure Sharing: This link is not available for you. You are logged in a User X but this account is not in the list of persons the link was shared with - free traanslation from a german error massage).

Please fix the email problem of getting two mails. This is not production ready.

Can you validate the scenario is working and my problem is only a lab hickup? I'm available through Skype for Business or any other communication capabilities to show the problem on my lab tenant.

Thanks for the clarity on this. Some more questions on this , After enabling this feature on tenant level will external sharing work for the users who were granted access in past using the link and were using Microsoft account to login?

2) Will external access be granted only through this process in future after enabling this feature (Microsoft account/Link external access being removed for future use).

@Rahul Rohra All existing access that had been granted will be preserved and those users can continue to access that content the same way they always have (by signing in to their Microsoft account or O365 account). For question #2, future external sharing will go through this new process only when sharing with external users that do not already have a Guest account in your directory.

@Marco Scheel Let me send you a private message and we'll take a deeper look at what is going on.

this feature is not enabled on a tenant level. This features replaces the default sharing currently used. At the moment in NON FR tenants a AAD account or Microsoft Account is required. After the rollout this is no longer the case. Any sharing activity will trigger the new sharing described in this post and the external party is not asked to login using a AAD or Microsoft Account.

At the tenant level the configuration will still be the same (based on the new or old admin UI):

The 3rd option is related to the current version (AAD guest account from AAD oder MSA) and the new version (email sharing+pin).

It gets complicated if the email you are using to invite an external is already in your AAD as an guest account. At this point the user will still have to login with his AAD account. This happens in the normal B2B environment like adding a Guest to an O365 Group. The intent is to make things easier... but I'm not sure this will be the case for most scenarios. Especially as current releases as Microsoft Teams guest access is relying on this B2B model.

Do you know if the roll out to users on First Release has completed? My tenant is not FR, but I have enabled a number of users for FR. We are not seeing the new secure external sharing experience for any of our FR users.

Hi @paul mitchell. This feature rolls out to individual tenants at a time. Right now all First Release tenants have the feature, but it does require the entire tenant to be First Release. For tenants that are not in FR then 10% of them currently have the feature. We're still targetting completed rollout by the end of the year.

I think there should be a way to tweak the new experience and perhaps provide an option to disable it, at least for users with Azure AD domains (work accounts).

The way this is configured at the moment prevents any sort of management of guest accounts (conditional access, MFA) and makes for a cumbersome experience when the user has to keep track of links and check emails for one-time passcodes. Further, as they are not logged in, can they seamlessly jump between documents?

In my testing I found two OTP emails were sent out per request and contrary to what the original post implies, the "External users must accept sharing invitations using the same account that the invitations were sent to" checkbox has no bearing on whether this new system is used or not.

Another point to consider is it's much easier for a guest user to circumvent policy by sharing a link to a single resource and forwarding the OTP by email or IM rather than having to share their corporate user/pass which carries greater privacy/security risks.

With this new system it seems in order to maintain control of guest accounts and discoverability of where they are used we will be forced to manually (batch) add users to AD B2B rather than allow the (old) SPO External Sharing workflow take care of it. This completely negates the original benefits of moving responsibilities of creating external user accounts to site/content owners rather than admins.

I think the idea is simply the sharing and let's be honest the orginal solution was always error prone to extern users not understanding teh different between Microsoft Account and Work & School. Once the process was understood it is a good solution. For the future you are not losing B2B functions related to AAD based accounts... you have to so some extra work and maybe up your license:

The current solution is a well known beast to longtime SharePoint Online users. We started back in the BPOS days. Lets pass another year and end of 2018 everything will seem fine as nothing changed because we adapted to the new "secure" sharing ;)

I can expand a little on some of your concerns as well. First, this doesn't replace the Azure B2B sharing system in any way. Users invited via this system will still be added into your organization's directory and will allow you to manage them just as you have before. Instead, this is meant to replace just the SharePoint/OneDrive specific method of sharing externally. As Marco mentioned, this could occasionally be something of a beast :). The older system was less secure and much harder to explain and use.

All that being said, please continue to give it a try and let us know how it goes and send us your feedback. Thanks!

I totally agree on the “occasional beast” part while I also totally disagree on the “old system less secure”. I’m pretty sure my AAD P2 protected, MFA secured, and Windows Hello for Business enrolled Surface Book is much more secure then a 6 digit pin a person can easily forward to anyone. In “light and quick” sharing scenarios it is more secure if the receiving end of the invite is less technical savvy and not enrolled in any AAD based workload. But as we (Microsoft and partners) are working for the same world domination in the cloud directory landscape as we did in the past for on-prem AD, the new solution is by far a less secure version. If the target audience is Gmail users (as in most demos) I totally agree the new solution is “more” secure compared to a poor google user signing of for a Microsoft Account (MSA) using his Gmail email address. Total confusion.

I’m coming from a shop supporting enterprise customers and while we also live and breath in AAD most B2B scenarios involves third parties already owning AAD identities. These scenarios are not the show cases that require the Microsoft “B2B Collaboration” process. It is light file and folder sharing and most of the times not Guest group membership what would be easy to setup for a typical end user hitting share in SharePoint. The Microsoft “B2B Collaboration” features (besides adding someone to an Office 365 group) are not self service ready compared what we had (some still have until end of the year) in SharePoint Online since the beginning of the service a few year ago.

Yes, agreed. I only meant to exactly the case you're describing: Sharing to a user who doesn't have a Microsoft account or an AAD account. Azure B2B and sharing directly to accounts that already exist in AAD are still fantastic, first class solutions for secure sharing. Thanks!

I'm still a little confused (see screen attachment). If I use internal, for example (only people in my organization) yet the sliders are set to "Anyone: users can create links that don't require sign-in" how exactly does that work? Are the selections in the top portion being overridden by the sliders being set to "Anyone"? I saw this asked somewhere else but I couldn't remember where (or the answer).

The slider at the bottom is setting the maximum level a user can use. Anyone will enable "Anonymous sharing". The radio button at the top controls the default method if someone is using the share dialog:

If you restrict sharing with anonymous users then one of the radio buttons will become inactive:

I sort of understand but this is still confusing to users (see attachment). If a user selects "Copy Link" on a OneDrive folder, for example, and it shows the default "only the people you specify.....", and they past this link into an email, what happens? In other words they believe they selected "Copy Link" as a quick way to share the document (whether for editing, reading, etc.) but can the person they send it to via email read, edit, etc. when the default is "only the people you specify..."? I realize that can be changed but it's a little confusing to the end user from the feedback I get.

@Marco Scheel is correct. The sliders control what the maximum amount of sharing that is allowed is while the default link chooses what the user will see by default. The idea is that you can give the users the ability to do all the sharing they need to do their job while still requiring them to make a deliberate choice to expand the audience.

The Copy Link behavior is definitely odd: Since the user hasn't specified anyone who to have access, the link won't work for anyone (though users who already have access may be able to still see the document). The experience could definitely be clearer though so I'll be forwarding your feedback along. Thanks!