One of the most typical "German problems" is the need to feel secure in terms of data protection. We aim to have a contract with anyone who does anything. Everyone entering a building should sign something, and ideally, anyone we speak to should confirm, preferably with a wax seal, that we are allowed to communicate with them.
In IT, this translates into wanting an explicit confirmation from every collaboration partner. Otherwise, we couldn’t "process" their audio and chat data. By the way, they’ll also appear in the file history on SharePoint. Maybe we also want non-disclosure agreements or codes of conduct confirmed at login, or something else along those lines.
For simplicity’s sake, let’s group all these digital documents under the umbrella term "Terms of Use" (ToU).
Recently, I had to compile the options for Terms of Use within M365. Since I couldn’t find a good summary during my research, I believe my findings could be valuable to others.
This first part will describe the settings that should apply to the entire M365 environment of an organization and all connected applications.
User Types
Since options and behaviors apply differently to various user types, let’s clarify some terminology upfront:
-
Internal Users: Users within your tenant. Their consent is typically confirmed through an employment agreement or contractual relationship. However, this group often includes contractors, for whom confirming Terms of Use is necessary.
Not "Internal Employees"! This refers to the technical account, not the user’s organizational affiliation.
-
Guests: External users explicitly invited to the tenant and required to authenticate.
-
Other/Anonymous Users: Users who are not invited to the tenant and do not authenticate. For example, they may appear as "Unverified" in Teams meetings.
With these terms clarified, let’s dive into the settings.
Privacy Statement URL
For Entra administrators, the most obvious place to host privacy information is in the "Overview" section of the Entra ID Admin Center.
Since only a URL can be stored, a web server is needed to host the corresponding content.
The same setting is also available in the M365 Admin Center, and changes made in one admin center automatically reflect in the other.
The slightly less detailed Microsoft documentation
This URL replaces the default Privacy Statement link in many (but not all) Microsoft 365 products (e.g., Teams and SharePoint).
Two examples:
| SharePoint Invite Link | "Teams Meeting Join Experience" |
|---|---|
 |
 |
Internal Users and Guests can also always view the Privacy Statement of the current organization on the MyAccount page:
In practice, these links are mostly accessed by data protection officers or users who enjoy reading terms and conditions. Theoretically, an anonymous user could stumble upon the URL if they visit a supported page. There is no enforcement to view or acknowledge these links. From a legal perspective this should suffice in most cases, however
⚠️ This is not legal advice! ⚠️
Tenant Login Page
An important exception to the "Privacy Statement" URL setting is the login process—the page where users sign in to the organization’s environment. Here, the "Company Branding" settings in the Entra ID Admin Center have to be set instead.
These settings only apply if Entra ID authentication is used! If ADFS or a third-party identity provider is federated, the login experience must be configured there.
By default, no footer is displayed during login. When enabled, both the text and URLs for "Terms of Use" and "Privacy and Cookies" can be customized for different purposes.
| Enable Footer | Set URLs |
|---|---|
 |
 |
For more information, see the Microsoft documentation.
It remains unlikely that a user will klick one of these links.
Conditional Access
If explicit acceptance of Terms of Use is required, Conditional Access is the only tenant-level solution.
Using a Conditional Access policy, users must confirm that they’ve read and accepted the uploaded PDF before accessing applications.
Key features include:
- Multilingual support: ToU can be provided in various languages.
- Mandatory expansion: Users can be required to expand the document before confirmation.
- Renewal: Consent can be re-validated after a set period.
Limitations:
- Since this is a Conditional Access feature, an Entra ID P1 license is required for all users under ToU enforcement.
- We are often asked to set a ToU for only Teams, SharePoint or Exchange. However, since M365 applications are so tightly interwoven, "Office 365" should always be treated as a single application – a ToU should cover all applications under this umbrella
- A maximum of 40 ToUs can be defined, so limit yourself on application specific ones.
- Conditional Access is part of the authentication process, therefore consent cannot be collected from anonymous users.
Configuration of ToU is already covered very well, here are some of the best resources I have seen:
- Blog-Post from the perspective of a citrix-administrator: How to use Azure AD Conditional Access to add a Terms of Use EULA
- Microsoft documentation: Terms of Use in Conditional Access
Summary
The options shown so far leave some challenges in coverage:
| Setting | Affected Users | Visibility | Explicit Confirmation |
|---|---|---|---|
| Tenant Privacy Info | All (context-dependent only Internal Users and Guests) |
MyAccount, M365 app pages, invites | ❌ Not required |
| Tenant Branding | Internal Users, Guests | Microsoft Login page | ❌ Not required |
| Conditional Access ToU | Internal Users, Guests | Upon login (with re-confirmation interval); separate ToU per Application possible (up to 40) | ✅ Required |
While gaps remain in addressing specific user types or requiring explicit consent, other options can complement these measures.
In Part 2, we’ll explore additional tools in Enterprise Apps, Teams, Intune, and Exchange to address existing gaps.
Comments