Introducing a new secure external sharing experience

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.  


Ensuring intended recipients get access 100% of the time: Identity verification 

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.


For additional information on the new external sharing experience in OneDrive for Business and SharePoint Online, read the New Sharing Features in First Release help article. 

Occasional Contributor

One of my customers is running as FR and now we are using the new Sharing Model. In my testing I was not using my real account but today I wanted to user my company AAD account to access a word document we are working on. In the browser I could access the word online version. The normal "Edit in Word" is missing:



In the Office Online version I can select "Edit in Word":



But in Word Desktop I'm not able to "sign in":


This is not working. I would expect that I will be prompted for a PIN in Office. If this is by design... this is BAD :)



Hi @Marco Scheel,


This is by design. The new external sharing flow is only available for the web at this time. We're currently investigating how this feature will work with the clients as well so stay tuned for more information. Thanks!


Stephen Rice

OneDrive Program Manager II

Occasional Contributor

Hi @Stephen Rice,


thanks for the info. I was getting more comfortable with this new way, but this fact is one again putting me down. I see the benefits of the new sharing model replacing the AAD guest based model, but this means that this way of sharing reduces the user experience dramatically :( I will also get used to tis fact an in most client scenarios we can work aground using B2B options. But I have a few high profile clients that are internally not ready to allow external guests in AAD groups and are now limited for the time being. I'm looking forward for an announcement for the removed features (Client apps).


Ciao Marco

Valued Contributor

Hi @Stephen Rose,

I love the verification codes for shareable links (with documents/folders), but is there any chance that this will come to sharing full sites with guests as well? 

I'm looking for a way to enable guest access to a site with very specific permissions that will be handled through SharePoint Groups, without the guest having to create an Microsoft ID.

Occasional Visitor

Do you happen to if/when the PnP javascript library will be updated to support sharing secure links?  Or, is there an example somewhere of how to use the PnP javascript to send a secure link?


UPDATE: I just tested the PnP 'shareObject' javascript method and it will create and email a secure link now.

Occasional Contributor

On the continual re-verification of identity. The blog states that IT administrators can now specify how often external recipients need to re-verify their email address. This has been set to 30 days in our organisation, however it appears every time external recipients attempt to use the shared link, a new verification code is sent...?  


"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."


Occasional Contributor

@Stephen Rose if a first time external share recipient has an Office365 subscription in their organisation. Are they able to access the shared link by signing in with their office365 account, instead of verification code method?

Occasional Contributor
As I understand it, if the user you attempt to share to doesn't already exist in your AAD as a guest user they will get a link + OTP if you share a file or folder. If you share a site you will have the old (imo better more secure :P ) experience using B2B and work accounts to authenticate.
Regular Visitor

I must be missing something because when I share with "Specific people" outside of the organization, they receive the same Open [Link] and then have to register if they don't have a Microsoft account. They are never receive or required to enter the verification code. Could this be because something isn't correct in the admin center?

@Ivan Unger Right now this is only for files and folders.


@John Tsalamandris External recipients need to check the "keep me signed in" box otherwise they will need to re-enter a code next time they click the link, even if that admin option is set to 30 days. For your second question, right now users only get asked to sign in if they have a Guest account which exists in that organization. If they don't already have a Guest account then they will be taken through the passcode flow.


@Shery Kirby It sounds like the feature isn't rolled out to your organization yet. It's currently rolled out to 50% of organizations. If you'd like to accelerate your access to it then you can enroll your organization into the First Release program for all users.

Regular Visitor

@Rafael Lopez-Uricoechea So, the actions are all available for use in the New Experience but ultimately when the external user receives the link it appears the same as the earlier email message and the user is redirected to the Microsoft sign in page, using Microsoft, Organizational, or Create a new account until the new sharing experience gets rolled out. Am I understanding you correctly?


@Shery Kirby That's the correct description for what would happen to organizations which do not yet have this feature rolled out to them.


I am testing this Ad-hoc external sharing method. It seemed if I use a hotmail account, I am able to get the one-time code. However, if I use other email accounts such as gmail or yahoo mail account, this doesn't work. here is the message I got from an GMAIL account when I try to open the secured link. Does it support gmail or yahoo mail or other non-MSA email account? Thanks.


ad-hoc sharing.PNG






Secure sharing works with all providers (gmail, yahoo, etc...) no MSA required. You will need to use that users email for the share and code. Also the code is a one time use code.


@Stephen Rose. thanks Stephen for quick response! Then what does "The link is not available to you" mean? I tried a few times already. thanks.

@Dean Chen That error message shows up when you are signed in with an account that doesn't match email address that the link is secured to. It looks like something is particularly odd there since the error message is supposed to include which email address you're currently signed into.


Can you try going to www.office.com and/or the root fo your sharepoint (http://tenant.sharepoint.com) to see what account you're currently signed into?


If you go back to gmail and open the link in a different browser or a private browsing session with no sign-in cookies then you should no longer see that message.


@Rafael Lopez-Uricoechea Thanks for the suggestion! After I cleared up the cached history in the browser or logged onto a different browser, my Gmail or Yahoo account worked with the secured link and with the one-time code as designed!


I do have a couple questions to understand this new secured sharing method.

1. At the tenant level in SPO, by default, we have 30 days setting under "Require recipients to continually prove access ownership when they access shared items". Does this 30-days mean, after 30 days, the secured link is no longer valid, correct? If the guest wants to continue to access the shared contents after 30 days, they would have to ask the sender to share the contents with a new email again, right?


2. As I understand the "One-time code" concept, it has to be sent over to the guest every single time when the guest clicks the link, is that correct?




@Dean Chen For #1 actually if you have this set to 30 days then it means that recipients who enter a code will have to re-verify their email address by entering a new code 30 days after they enter the first one, even if they checked the "keep me signed in" box. So for example if you send me a secure link on December 1st and I enter in the code and click "keep me signed in", when I come back on December 30th I'll be asked for a new code. The link itself still will continue to work and I don't have to ask you for re-share the content with me.


This feature is primarily meant to protect against employment changes for recipients. For example if on December 1st I work for Contoso and have rafael@contoso.com but then by December 30th I left Contoso, then I won't be able to re-verify my rafael@contoso.com email address and so will lose access to the content that you shared with my Contoso identity.


For #2 it depends on whether the recipient clicked on "keep me signed in". If they do not check that box then the code is only valid for that browsing session. If they close their browser then they'll need to click on the link again and enter in a new code.


@Rafael Lopez-Uricoechea Understand. I will continue to test. If I have any new questions, I will post them there. :)  Thank you!

Occasional Visitor

I have mixed feelings about this change.  


Firstly although we received the message in September that it was slowly rolling out, we didn't get any further messages and so last Wednesday we started getting tickets from users that their partners (outside the organisation) were complaining they couldn't get to content.  Turned out we had been rolled to the new experience without any further communications or warning - that needs to improve.


I saw elements of this at Ignite back in September so I knew when customers explained what they were seeing that we had been 'upgraded'.


To the feature itself.  

1) Yes it makes adhoc sharing a little easier, previously some customers didn't get the 'Do you have a Microsoft account / O365 Account' screen.  I struggle what was difficult about it but whatever.  So on that point yep the verification code is a different approach and for some folk easier.


2) However if I invite say 6 external people to share a folder so we can collaborate then they all get that code and under permissions I see one entry, the link with a little 'x' to the right of it (more on that later) and underneath it small grey circles for each of the 6 people I shared it with.  Say I no longer want to share with 1 of those folk, I can't remove just that one.  I have to kill the link completely and reinvite the other 5 people - they then get a new link.


3) That link.  That link needs to be kept and if it changes as per item 2 then it needs to be updated - that's a pain.  Our users can't just send them a link to the folder and have them go through the login screen as they did previously.  They have to remember when they send emails to the whole team that these 6 people have a different link to everyone else.  And if they invite some more external people that will be another weird link.   In just a few days for one of our external collaborations we have 3 of these odd verification code links and of course the 10 or so internal people.  That means for every update email they have to send 4 links out and inform folk which link to click on to keep up to date on progress on the project. - that's absolutely horrible.


4) If I do have a long term external partner that we are working with then the best way is actually to onboard them into AD.  This now becomes an IT ticket that the colleague has to submit and our managed service has to execute.  Its also something the colleague has to think about up front.  In the previous solution (last Tuesday) they just emailed them and they got added to AD.  So an IT burden and a colleague burden has been added.


Overall I think the idea is good but the implementation is weak and not well thought out.  Longer beta testing of this feature with companies that do large amounts of external collaboration would have been good.  I also feel there needs to be a colleague option that lets them choose between 1-time adhoc collaboration and long term collaboration ie. verification code or onboard.  The verification codes sent need to be broken into distinct permission entries, ie. an invite to 6 people should result in 6 distinct permission entries, not 1 link with 6 people listed under it.


This change really hurts us and to be honest its pushing us away from O365 towards Box and other solutions.


Occasional Contributor

Is the token authentication a forced change?  My understanding was yes but in looking at this it appears it is a check box that is optional.


Screen Shot 2018-01-02 at 1.35.33 PM.png


Second, if this is enabled then there is no way to share a site with an external party?  

Hi @Brett Cox. The checkbox you’re seeing does not control whether this feature is enabled or not. Instead, it is an optional feature (off by default) which lets you specificity how often recipients need to re-verify their email. For example if you share with amy@contoso.com and this checkbox is set to 30 days, then when Amy enters in the code to access the file/folder, she will have to do the same thing again 30 days later (even if she selected to be kept signed in). This way, if she loses access to her email account (for example if her employment status changes) then she also loses access to that shared item (because she can’t enter the new code).


Does that make sense?


For site sharing, you can still share externally but for now it will use the previous system that requires that recipients create accounts.

Occasional Contributor

@Rafael Lopez-Uricoechea Thanks, makes sense.  What is still not clear to me then is how this new token sharing is managed in the SP admin portal.  I do not see anything new in the portal.  I thought we were going to set the validity period for the token.  Is the only way to set a validity period for the token sharing via the method in my message above?  Is the token roll-out complete?

@BRETT COX Based on your screenshot this feature has already rolled out to your tenant.


You can limit the type of external sharing allowed in your tenant or in specific groups/sites. This flow is enabled when your external sharing is set to allow new external users. If you turn external sharing off, or you limit it to only existing users in the directory then no users will go through this flow. But when you allow sharing to new external users then this flow will be used during secure sharing and there’s no way for admins to revert to the old experience.


The code itself can only be used once and must be used within 15 minutes of it being generated (it gets generated when the recipient clicks on the link). Once the code is entered, by default it will only allow access to the shared resource for the length of the browser session. If the browser session ends and the user clicks on the link again in a future session then a new code will be generated and sent to the email address the link is secured to.


If end users/recipients do not want to have to re-enter codes on every new session, they can choose the “keep me signed in” checkbox on the code verification page. When they do this, the access to the file will persist beyond the browser session. They can close their browser and open it again. When they click the link they will not be asked for a new code.


By default they can do this indefinitely (as long as they manually checked “keep me signed in”) but the setting in your screenshot allows admins to set a time limit  for when recipients have to get a new code, even if they had checked to be kept signed in.