Electronic Signatures in Microsoft 365: Using eSignature Without Leaving Your Tenant

Watching people in 2026 still print out Word documents, sign them by hand, scan them and send them back by email feels a bit surreal. We have video calls with AI live captions, but contracts still travel as PDFs that bounce between inboxes.

For a long time the default answer was: “Just use DocuSign / Adobe Sign / whatever, upload the PDF and let people sign there.” That works. But it also means:

• another platform, another login,
• extra subscriptions just for signatures,
• and documents leaving your Microsoft 365 environment.

Since late 2025, there’s another option that a lot of people seem to miss: Microsoft 365 eSignature. It lets you request and collect electronic signatures directly in M365 – and it can even sit on top of existing providers like Adobe Sign and DocuSign.

In this post I’ll walk through:

• what M365 eSignature actually is,
• what you need to use it, and where the limits are,
• a simple, practical signing flow with Power Automate,
• and how I’d think about security and identity when you modernise your signing process.

What Microsoft 365 eSignature actually is

eSignature is a feature in the SharePoint Premium / Microsoft 365 ecosystem that lets you:

• request signatures,
• sign documents,
• and store the signed versions

directly inside Microsoft 365:

• SharePoint document libraries,
• OneDrive,
• and the desktop/web versions of Word (Enterprise).

The core idea is simple:

You shouldn’t have to upload your contract to a third-party website just to get a legally valid electronic signature.

On top of that, if your company already uses Adobe Acrobat Sign or DocuSign, you don’t have to throw them away. M365 eSignature can use them as providers under the hood:

• users stay in the M365 UI,
• your existing eSignature provider still handles the actual signing workflow and compliance,
• and you avoid a tool zoo from the end-user perspective.

Requirements and the guest-account catch

The basic requirements to use eSignature are:

• an Azure subscription with billing enabled (pay-as-you-go for document processing),
• Enterprise Office apps if you want to start signing directly from Word.

Pricing is usage-based; you pay per document/signature transaction. Microsoft has a dedicated pricing page for that on Learn.

There’s one important catch that the docs sometimes mention only briefly:

People who sign via M365 eSignature need to be users or guests in your tenant.

In other words:

• Internal staff: no issue, they’re already in Azure AD / Entra ID.
• External signers: need a guest account (B2B) to access the document and sign it.

For some organisations that’s totally fine – they already collaborate with partners via guests in Teams/SharePoint. For others, guest access is tightly locked down or historically disabled, so this becomes an organisational and security conversation before it becomes a technical one.

A simple signing flow in M365

Let’s look at a practical scenario:

“We have a contract as a Word document in SharePoint. We want it signed by one or more people. Once it’s signed, it should live in a ‘Signed Contracts’ library and relevant people should be notified.”

On a high level, the flow looks like this:

Option 1: start directly from Word / SharePoint

This is the simplest option:

• Author saves the document in a specific SharePoint library.
• In the UI, they choose something like “Request eSignature”.
• They select signers (internal users and/or guests).
• M365 eSignature sends out the sign requests and tracks completion.

The final signed document ends up back in the same place (or a configured destination), with an audit trail.

Option 2: embed it into a Power Automate process

If you want to treat signing as just one step in a longer business process, Power Automate is the natural place to glue things together.

Very simplified:

Trigger: When a file is created or modified in Library "Contracts"
Action:  Get file metadata
Action:  Start eSignature request (document = file, signers = metadata.Signers)
Action:  Wait for eSignature status = Completed
Action:  Copy signed document to Library "Signed Contracts"
Action:  Post message in Teams channel "Legal" with link to signed file

Depending on your license and the eSignature provider you use (native M365 vs. Adobe/DocuSign connector), the exact actions differ, but the pattern stays the same: document in, signature request out, signed document back in, plus notifications.

Identity and security: who may see and sign what?

As soon as signatures are involved, identity and security move to the front of the stage.

A few principles I keep in mind:

1. Signatures are only as strong as your identity

The value of an electronic signature depends on:

• how strong the identity verification is,
• how good your audit trail is (who signed what, when, from where),
• and whether you can show that the document didn’t change after signing.

Using M365 identities – including guests – is not a workaround, it’s part of that chain of trust. If you’re serious about compliance, you want signers to be tied to proper identities, not anonymous links.

2. “Can see” and “can sign” are different roles

Someone being allowed to view a file in SharePoint doesn’t automatically mean they should be allowed to sign it.

In practice it helps to distinguish:

• readers (can view the document),
• approvers (can give internal approval, e.g. via Power Automate approvals),
• signers (can legally sign the document).

When you design your libraries and flows, it’s worth taking five minutes to map these roles to groups/permissions instead of letting “whoever can open the file” also be in the signer list.

3. Don’t build God-mode Flows

There’s a similar anti-pattern here as with Copilot connectors: using a single service account that can see and sign everything.

Where possible:

• use dedicated service identities with scoped permissions (e.g. only certain libraries),
• avoid giving Flows blanket rights to every contract library in the organisation,
• log who requested a signature for which document and which signers were added.

It’s very easy to accidentally turn “streamlined signing” into “anyone with access to the Flow can make anyone sign anything”. You want to avoid that.

How this fits with external providers like Adobe/DocuSign

In a lot of organisations, Adobe Acrobat Sign or DocuSign are already in place for critical contracts, with legal and procurement being comfortable with their processes.

In that case, I wouldn’t see M365 eSignature as a replacement so much as a new front door:

• make the user experience more consistent (requests from SharePoint/Word instead of from a separate portal),
• keep signed docs in your existing SharePoint structures,
• and let Adobe/DocuSign continue doing what they’re already doing well in the background.

For “lighter” internal documents, you might decide the native M365 eSignature path is enough. For high-stakes, high-risk contracts, you keep the dedicated provider and just surface it through M365.

A quick note on legal aspects

I’m not a lawyer, so this is not legal advice. But roughly:

• Electronic signatures are recognised in many jurisdictions, with different levels (simple, advanced, qualified).
• Which level you need depends on the type of document and local regulations.
• Large providers (including Microsoft + integrated partners) typically have detailed guidance on which of their options meet which legal standards.

The practical takeaway for me:

• don’t over-engineer simple internal approvals – eSignature is often good enough there,
• for critical, regulated use cases, involve Legal and stay on the supported path of your chosen provider.

My take: where M365 eSignature makes sense

For me, Microsoft 365 eSignature is most interesting in three situations:

1. Internal agreements and routine contracts
   Stuff like NDAs, internal approvals, standard vendor contracts, where the main pain is the ping-pong of PDFs and email.
2. Teams that already live in M365
   If your users spend most of their day in Teams, SharePoint and Outlook, keeping the signing flow in that world removes friction.
3. Organisations with a mix of needs
   You can use native eSignature for “lightweight” cases and still integrate your heavyweight provider for the contracts that really matter.

The main thing I’d keep in mind is the same theme that came up in my Copilot posts: identity and security are not an afterthought.

If you take the time to:

• clean up who is allowed to see and sign what,
• design your libraries and Flows with clear roles,
• and avoid god-mode service accounts,

then M365 eSignature can turn a surprisingly stubborn part of your process – “print, sign, scan” – into something that finally fits the rest of your digital workspace.