Short answer: the Msafe Connector for Outlook is an add-in that lets employees share confidential files from Outlook through Msafe, instead of as a regular email attachment. The message goes by email, the file stays in Msafe: with recipient verification, an expiry date, revocable access and an audit trail. The Connector only works in Outlook. Other applications can be integrated through the Msafe API.
Updated on 5 November 2026
Employees work in Microsoft 365 every day. Confidential files are stored in OneDrive or SharePoint and are often shared from Outlook with customers, suppliers and other external partners. That transfer point requires additional control, without forcing users into a separate and cumbersome process. That is where secure file transfer for Microsoft 365 comes in.
The Msafe Connector brings secure file sharing into Outlook, the application employees already use for their email. An employee initiates the transfer from Outlook; Msafe then manages the controlled delivery, recipient verification, availability period and recording of relevant events. Read also what the new Microsoft Hero Link changes in SharePoint and OneDrive.
This allows Microsoft 365 and Msafe to serve complementary purposes: Microsoft 365 supports productivity, storage and collaboration, while Msafe provides controlled and demonstrable exchange of confidential files with external parties.
Why Microsoft 365 needs secure file transfer
Microsoft 365 already protects a lot. Microsoft Purview Message Encryption encrypts email so that only the intended recipients can read it. Yet one gap remains in daily work: transferring files securely to people outside the organisation, especially when they are large or confidential.
- Attachment limits. Exchange Online allows 35 MB per message by default, and up to 150 MB if administrators raise it. Larger files simply don’t fit. Read more in send large files securely.
- Sharing links need managing. OneDrive and SharePoint can share larger files, but someone has to manage access, links and guest settings. And with the new Microsoft Hero Link, existing link expiry policies don’t apply.
- Evidence. Regulations such as the GDPR and NIS2 ask organisations to demonstrate appropriate measures. A transfer-focused audit trail makes that much easier than piecing together mailbox and sharing logs.
Secure file transfer for Microsoft 365 closes that gap without changing how people work. Employees stay in Outlook, while Msafe handles verification, expiry and logging of the external transfer.
What is the Msafe Connector for secure file transfer in Microsoft 365?
The Msafe Connector is an add-in for Outlook. Once deployed, users see a recognisable option in Outlook for sharing a file through Msafe. They do not need to open a separate portal.
The Connector links the familiar user action to Msafe Secure File Transfer. The source application continues to operate independently, while the external transfer is handled in Msafe’s separately managed and secured environment.
For the employee, this feels like one continuous task. For IT, security and privacy teams, it creates a more clearly governed process with policies for recipients, permissions, verification, expiry, revocation and logging.
Where does the Msafe Connector work?
The Msafe Connector works in Outlook. Employees share one or more files from their email workflow without sending them as standard attachments.
There is no Msafe Connector for OneDrive or SharePoint. Those environments remain the place for storage and collaboration. When a confidential file needs to go to an external party, the employee sends it through Msafe from Outlook or from the Msafe web application at use.msafe.nl. To use Msafe in other applications, you can connect them through the Msafe API.
Secure sharing from Outlook
With a standard email attachment, the sender loses most operational control immediately after sending. The attachment is stored in mailboxes, can be forwarded and may remain available for longer than intended.
With the Msafe Connector, the user initiates a protected transfer from Outlook. The process generally follows these steps:
- The employee prepares the email and selects the Msafe sharing option.
- The employee selects the files and intended recipients.
- Appropriate access conditions are selected or applied automatically through policy.
- The recipient receives an invitation to the protected transfer rather than an unmanaged email attachment.
- Relevant events are recorded in the Msafe audit trail.
The file size is not governed by the normal email-attachment limit: Msafe supports files up to 1 TB as standard, and larger files on request. This is useful for drawings, media files, datasets, case files and other large or sensitive documents.
OneDrive and SharePoint: collaboration, not transfer
OneDrive and SharePoint are well suited to storage, version control and collaboration within Microsoft 365. Microsoft also supports external collaboration through several link and guest models. Available options are governed by tenant, site and sharing settings.
Microsoft explains these models and the interaction between organisation- and site-level policies in its Microsoft guidance on external sharing. The most restrictive setting applies.
Msafe adds a different route for situations in which the objective is not long-term collaboration within a site, but the controlled transfer of a file to an external party. The employee starts that transfer from Outlook or from the Msafe web application. Recipient permissions and evidence are then managed within the Msafe process.
An organisation therefore does not have to choose between Microsoft 365 and Msafe. The appropriate route is selected for each information flow: Microsoft 365 for collaboration and co-authoring, or Msafe for controlled sending and receiving.
Access control, expiry and audit trail
A secure transfer involves more than encryption. The organisation must also be able to determine who receives access, how long that access remains valid and which actions can be demonstrated afterwards.
- Recipient verification: depending on policy, access can be protected with a PIN, SMS or authenticator app.
- Permissions: define the actions available to the recipient in the selected Msafe workflow.
- Expiry and retention: avoid keeping files available for longer than necessary.
- Revocation: withdraw access while the file remains available through the platform.
- Audit trail: record uploads, shares, access, downloads, deletions and digital signatures when those functions are used.
Additional verification should reflect the risk. The NIST Digital Identity Guidelines explain the relative assurance of different authentication methods. See also how 2FA for secure file sharing can be implemented on a risk-based basis.
An audit trail demonstrates events within the platform, but does not automatically prove who was physically operating a device. A locally downloaded copy also cannot normally be deleted remotely. Reliable governance therefore combines logging with clear permissions, verification, classification and agreements with recipients.
What does an audit trail prove, and which security information do you get elsewhere?
An audit trail is strong evidence, but only for what it records. In Msafe it shows, per document, which action took place, by which identity, when, and under which restrictions: upload, share, recipient verification, access, download, expiry and revocation. That makes demonstrability concrete. You can show who received a contract, whether they verified themselves and when access ended.
What an audit trail does not show is activity that never reaches the platform. Microsoft gave a clear example on 29 October 2026: attackers can discover usernames by probing OneDrive and SharePoint URLs, and according to Microsoft these probes do not appear in Microsoft Entra sign-in logs or Microsoft Purview. Microsoft classifies the technique as low risk, because it is passive and does not bypass authentication. But the account names it reveals can support targeted phishing and credential attacks. This is new guidance on an existing technique, not a new data breach.
That is why it helps to separate three layers, each with its own purpose:
- Document activity: the Msafe audit trail records what happened to a shared file, by which identity and with which restrictions.
- Access control: Msafe enforces recipient verification, expiry and revocation per transfer, so a known username alone does not open a file.
- Identity security: detecting reconnaissance and account attacks belongs in your identity and email security, such as Entra MFA, Conditional Access, sign-in risk policies and phishing protection.
No single log covers everything. For demonstrable compliance, know which log answers which question. The management guide Control over secure file sharing works this out in four steps: policy, access, use and evidence.
What does the recipient see?
The recipient receives an email containing a clear invitation and protected access to the shared files. Depending on policy, the recipient first completes a verification step, such as entering a PIN, SMS code or code from an authenticator app.
An external recipient does not always require a full Msafe account. Guest access can provide browser-based access once the configured conditions have been met. The sender can limit availability and revoke access while the file remains available within Msafe.
The recipient experience remains straightforward: open the invitation, verify identity or access and view or download the file within the permitted options. In an enterprise deployment, the environment can also reflect the sending organisation’s branding and communication style.
Implementation and administration
The Outlook integration operates as an add-in and does not require changes to the email server to send files through Msafe. Msafe runs as a separate SaaS environment. Organisations can therefore introduce the solution in phases without redesigning their entire Microsoft 365 environment. Because Msafe is delivered as SaaS, no extra hardware or server maintenance is needed, and the Outlook add-in is available through Microsoft Marketplace.
Microsoft’s Microsoft 365 integrated apps portal gives administrators central options for assigning apps and add-ins to users and groups. Microsoft’s general guidance on Microsoft guidance on Office Add-ins describes the available distribution methods.
A controlled implementation usually includes the following steps:
- Identify the information flows and user groups for which the Connector is required.
- Define secure defaults for recipient verification, permissions, expiry and retention.
- Configure Single Sign-On through Microsoft Entra ID where appropriate.
- Test the Outlook add-in with representative files and genuine external recipients.
- Review audit information, exceptions and user experience before wider deployment.
- Embed user onboarding, changes and offboarding in the regular identity process.
In larger environments, a SCIM integration can further automate user and group administration. The precise implementation depends on licensing, Microsoft 365 configuration and the selected security policy.
How is this different from a standard Microsoft sharing link?
A Microsoft sharing link is not inherently insecure. OneDrive and SharePoint provide mature capabilities for collaboration and external sharing. The main difference is the primary purpose and the way the organisation wants to govern and demonstrate the process.
| Area | Standard Microsoft sharing link | Sharing through the Msafe Connector |
| Primary purpose | Collaborate on or provide access to content in Microsoft 365 | Controlled transfer of files to internal or external recipients |
| Starting point | OneDrive or SharePoint | Outlook or the Msafe web application |
| Access | Governed by tenant, site, link and guest settings | Governed by Msafe policy for recipient, verification, permissions and validity |
| Availability | Configurable within the available Microsoft sharing options | Expiry and retention within the Msafe transfer |
| Revocation | Remove the link or guest permissions in Microsoft 365 | Revoke access to the transfer while the file remains available through Msafe |
| Evidence | Audit and activity information in the Microsoft 365 management landscape | Transfer-focused audit trail with relevant events relating to the shared files |
| Best fit | Ongoing collaboration, version control and co-authoring | Targeted external transfer with separate policy and demonstrable evidence |
The right choice therefore follows from the use case. Read SharePoint versus Secure File Transfer for a more detailed decision framework.
Frequently asked questions about the Msafe Connector for Outlook
Use Microsoft 365 for storage and collaboration, and add a secure file transfer solution for external transfers. With the Msafe Connector, employees start the transfer from Outlook, while recipient verification, expiry, revocation and the audit trail are handled in Msafe.
No. The Connector uses Microsoft 365 as the trusted starting point and adds a specialised transfer process. OneDrive and SharePoint remain suitable for storage and collaboration; Msafe focuses on controlled external sharing.
No, there is no direct Msafe Connector for OneDrive or SharePoint. The Connector works in Outlook. OneDrive and SharePoint remain suitable for storage and collaboration. For a controlled external transfer, employees use Msafe from Outlook or from the Msafe web application. Other applications can be integrated through the Msafe API.
No. Security depends on configuration, link type, guest policy, permissions and user behaviour. Msafe is particularly relevant when the organisation wants one separate, transfer-focused process for verification, expiry, revocation and audit information.
Not always. Depending on policy and configuration, guest access can use a PIN or 2FA. An account may still be appropriate for established collaboration or more extensive permissions.
Yes, while the file remains available through Msafe. A copy that the recipient has already downloaded locally cannot normally be removed remotely.
Yes. Msafe supports files up to 1 TB as standard, and larger files on request, well beyond the normal limit for an email attachment.
Microsoft 365 administrators can assign the Outlook add-in to users and groups. That allows a phased rollout, for example starting with a pilot group.
Request a demo
The value of secure file transfer for Microsoft 365 becomes clear in the actual workflow. A useful evaluation should test not only whether a file can be sent, but also whether employees naturally choose the secure route and whether IT can retrieve the required information afterwards.
For a demonstration or proof of concept, use a representative file shared from Outlook, a genuine external recipient and your own requirements for verification, expiry, retention and audit trail.
Would you like to assess how the Msafe Connector fits your Microsoft 365 environment? Request a demonstration or proof of concept. Together, we can map the most important information flows and test the complete journey from employee to recipient.
