Microsoft Entra Terms of Use can be configured to stop a user from reaching Microsoft 365 until they acknowledge an organization’s PDF agreement, using Conditional Access as the enforcement point. A walkthrough published on YouTube on August 7 demonstrates the full path: upload a custom document, attach it to a Conditional Access policy, target a test user and Microsoft 365, then inspect the resulting consent record after sign-in.
The important operational point is that this is not a document-hosting feature or an advisory sign-in banner. When the policy applies, accepting the terms becomes a grant requirement for the selected cloud resource. A user who declines cannot access the app until they sign in again and accept. Microsoft’s Entra documentation confirms that Terms of Use is evaluated during interactive sign-in alongside other Conditional Access controls.
For Microsoft 365 administrators, that makes the feature useful for more than an annual acceptable-use-policy exercise. It can put a recorded acknowledgement in front of access to a collaboration tenant, a protected application, a guest-sharing workflow, or a device-enrollment process. It can also create a far more disruptive rollout than the friendly-looking PDF upload screen suggests.
The video correctly frames the setup around Microsoft Entra Conditional Access. The Terms of Use object holds the document, language versions, expiration settings, and acceptance configuration, but it does not restrict anyone by itself. Access changes only when an administrator creates a Conditional Access policy that selects users or groups, targets one or more resources, and requires the specified Terms of Use under the policy’s grant controls.
That distinction determines the real scope of an implementation. A policy aimed at Microsoft 365 reaches the cloud resource selected in the policy; it is not a blanket control over every Windows device, every local file, or every service that happens to be used by employees. Administrators should verify the exact resource assignment rather than relying on a broad internal description such as “Microsoft 365 terms.”
Microsoft’s documentation says Terms of Use can be applied to enterprise applications that use modern authentication. That is a meaningful limitation for older environments. If an organization still relies on legacy authentication paths, inherited line-of-business tooling, or non-interactive access methods, a Terms of Use prompt is not a universal catch-all. The policy is part of Entra’s token and sign-in decision process, so it is most dependable where the application participates in that process.
The video’s test-user approach is the correct way to begin. Microsoft recommends placing new Conditional Access policies in report-only mode to understand their effect before enabling them. A Terms of Use policy may appear simple, but once applied to a widely used cloud app it becomes an access dependency for every included identity.
Those options serve different administrative purposes and should not be switched on together without a clear policy reason. An annual policy acknowledgement might use a fixed expiry date, which can line up the whole tenant for reacceptance on a common schedule. A contractor agreement might instead use a number of days from acceptance, producing individualized renewal dates. Microsoft notes that organizations can technically use both expiry methods, but normally should choose one.
The catch is in the session behavior. Expired consent does not necessarily interrupt a user at the instant a calendar date arrives. Microsoft says users whose consent has expired are prompted to reaccept when their session expires. Likewise, updating a document and enabling reacceptance does not force an in-session user to accept immediately; the prompt arrives when they next seek access after the relevant session state has expired.
That changes how an organization should handle a material policy revision. If the revised text must take effect by a precise deadline, simply uploading it with the reacceptance toggle may not provide the immediacy legal, HR, or security teams expect. Microsoft’s own documentation points out that deleting and recreating the Terms of Use policy, or creating a new one, is the more forceful option when reacceptance must be ensured. That route has its own consequence: deleting the old terms also deletes the acceptance records associated with that Terms of Use object.
In other words, Entra gives administrators an acknowledgement mechanism, version history, and acceptance data. It does not eliminate the need to design how policy changes, evidence retention, and access interruption fit together.
That is a useful compliance and help-desk trail. An administrator can distinguish a user who never saw the prompt from one who declined, identify which document version was accepted, and investigate a sign-in sequence around the acknowledgement. Users can also view the Terms of Use statements they have accepted through their work-account privacy settings.
But the records are not an archive independent of the tenant’s configuration. Microsoft says the Terms of Use acceptance data is retained for the life of the Terms of Use policy, while audit-log retention depends on licensing. More significantly, Microsoft says acceptance records are deleted if an administrator deletes the Terms of Use policy, if the tenant loses its Entra ID P1 or P2 licensing, or if the tenant itself is deleted.
For organizations that need long-lived evidence of acknowledgement, that should settle the operational question: export and preserve the relevant records under the organization’s own retention process. Leaving the data solely inside a live Entra configuration turns a policy cleanup or license change into a potential record-retention event.
That is expected evaluation order, not necessarily a failed acknowledgement. The related sign-in records can share a correlation ID, and the sequence needs to be reviewed together. Help-desk teams should know this before a rollout; otherwise, an ordinary user completing MFA and accepting a document can generate what looks like an unexplained Terms of Use failure in the logs.
The order also reinforces why this control belongs in a tested Conditional Access design rather than an ad hoc compliance project. Existing policies for MFA, device compliance, approved apps, sign-in frequency, location restrictions, and risk can all affect the path a user sees before the PDF appears.
Administrators should also account for the interactive requirement. Microsoft states that Terms of Use can only be accepted during interactive authentication, which means it is unsuitable as a direct control for PowerShell or other non-interactive sign-in workflows. Microsoft further advises excluding service accounts from Terms of Use Conditional Access policies; service accounts cannot satisfy a human acknowledgement screen.
Microsoft documents several constraints. Per-device Terms of Use does not support Entra B2B users, and the Microsoft Intune Enrollment app must be excluded from a Terms of Use policy using this option. Administrators deploying device enrollment should not assume that one policy fits both initial enrollment and per-device acknowledgement; Microsoft treats those as separate scenarios.
The browser experience also matters. Microsoft warns that users who are not using per-device Terms of Use can be prompted at every sign-in in Microsoft Edge if their work profile is not synchronized. The practical fix is to have the user sign into and sync their work Edge profile, allowing single sign-on state to recognize the earlier acceptance. Without that preparation, a policy designed to be accepted once can generate repetitive prompts and a misleading perception that the system has lost consent.
For Microsoft 365 administrators, that makes the feature useful for more than an annual acceptable-use-policy exercise. It can put a recorded acknowledgement in front of access to a collaboration tenant, a protected application, a guest-sharing workflow, or a device-enrollment process. It can also create a far more disruptive rollout than the friendly-looking PDF upload screen suggests.
Conditional Access, Not Microsoft 365, Does the Blocking
The video correctly frames the setup around Microsoft Entra Conditional Access. The Terms of Use object holds the document, language versions, expiration settings, and acceptance configuration, but it does not restrict anyone by itself. Access changes only when an administrator creates a Conditional Access policy that selects users or groups, targets one or more resources, and requires the specified Terms of Use under the policy’s grant controls.That distinction determines the real scope of an implementation. A policy aimed at Microsoft 365 reaches the cloud resource selected in the policy; it is not a blanket control over every Windows device, every local file, or every service that happens to be used by employees. Administrators should verify the exact resource assignment rather than relying on a broad internal description such as “Microsoft 365 terms.”
Microsoft’s documentation says Terms of Use can be applied to enterprise applications that use modern authentication. That is a meaningful limitation for older environments. If an organization still relies on legacy authentication paths, inherited line-of-business tooling, or non-interactive access methods, a Terms of Use prompt is not a universal catch-all. The policy is part of Entra’s token and sign-in decision process, so it is most dependable where the application participates in that process.
The video’s test-user approach is the correct way to begin. Microsoft recommends placing new Conditional Access policies in report-only mode to understand their effect before enabling them. A Terms of Use policy may appear simple, but once applied to a widely used cloud app it becomes an access dependency for every included identity.
The Consent Prompt Has More State Than It Appears To
Microsoft Entra can require a user to expand the PDF before accepting it, present localized PDFs based on browser-language preference, and retain historical document versions. It can also require acceptance on every registered device, set an expiry schedule, or demand reacceptance after a new PDF version is uploaded.Those options serve different administrative purposes and should not be switched on together without a clear policy reason. An annual policy acknowledgement might use a fixed expiry date, which can line up the whole tenant for reacceptance on a common schedule. A contractor agreement might instead use a number of days from acceptance, producing individualized renewal dates. Microsoft notes that organizations can technically use both expiry methods, but normally should choose one.
The catch is in the session behavior. Expired consent does not necessarily interrupt a user at the instant a calendar date arrives. Microsoft says users whose consent has expired are prompted to reaccept when their session expires. Likewise, updating a document and enabling reacceptance does not force an in-session user to accept immediately; the prompt arrives when they next seek access after the relevant session state has expired.
That changes how an organization should handle a material policy revision. If the revised text must take effect by a precise deadline, simply uploading it with the reacceptance toggle may not provide the immediacy legal, HR, or security teams expect. Microsoft’s own documentation points out that deleting and recreating the Terms of Use policy, or creating a new one, is the more forceful option when reacceptance must be ensured. That route has its own consequence: deleting the old terms also deletes the acceptance records associated with that Terms of Use object.
In other words, Entra gives administrators an acknowledgement mechanism, version history, and acceptance data. It does not eliminate the need to design how policy changes, evidence retention, and access interruption fit together.
Acknowledgement Records Are Useful, but Retention Needs Planning
The walkthrough also shows where to review accepted Terms of Use records. Microsoft Entra’s Terms of Use page provides accepted and declined counts, current acceptance state, individual histories, version-level views, and an option to export details. Audit logs also record policy changes and user-consent events.That is a useful compliance and help-desk trail. An administrator can distinguish a user who never saw the prompt from one who declined, identify which document version was accepted, and investigate a sign-in sequence around the acknowledgement. Users can also view the Terms of Use statements they have accepted through their work-account privacy settings.
But the records are not an archive independent of the tenant’s configuration. Microsoft says the Terms of Use acceptance data is retained for the life of the Terms of Use policy, while audit-log retention depends on licensing. More significantly, Microsoft says acceptance records are deleted if an administrator deletes the Terms of Use policy, if the tenant loses its Entra ID P1 or P2 licensing, or if the tenant itself is deleted.
For organizations that need long-lived evidence of acknowledgement, that should settle the operational question: export and preserve the relevant records under the organization’s own retention process. Leaving the data solely inside a live Entra configuration turns a policy cleanup or license change into a potential record-retention event.
MFA and Terms of Use Can Produce Misleading Sign-In Logs
Microsoft’s grant-control documentation highlights a detail likely to surprise administrators testing the policy. When both multifactor authentication and Terms of Use are required, Conditional Access validates MFA before Terms of Use. A sign-in that needs MFA can therefore show an interruption and a Terms of Use failure before a subsequent record shows successful MFA and Terms of Use validation.That is expected evaluation order, not necessarily a failed acknowledgement. The related sign-in records can share a correlation ID, and the sequence needs to be reviewed together. Help-desk teams should know this before a rollout; otherwise, an ordinary user completing MFA and accepting a document can generate what looks like an unexplained Terms of Use failure in the logs.
The order also reinforces why this control belongs in a tested Conditional Access design rather than an ad hoc compliance project. Existing policies for MFA, device compliance, approved apps, sign-in frequency, location restrictions, and risk can all affect the path a user sees before the PDF appears.
Administrators should also account for the interactive requirement. Microsoft states that Terms of Use can only be accepted during interactive authentication, which means it is unsuitable as a direct control for PowerShell or other non-interactive sign-in workflows. Microsoft further advises excluding service accounts from Terms of Use Conditional Access policies; service accounts cannot satisfy a human acknowledgement screen.
Per-Device Consent Has Specific Exceptions
The video mentions per-device acceptance as an available option, but it is the setting most likely to create rollout surprises. Per-device Terms of Use relies on an Entra-registered device and its device ID. It is intended for situations where a user should acknowledge conditions separately on each device they use.Microsoft documents several constraints. Per-device Terms of Use does not support Entra B2B users, and the Microsoft Intune Enrollment app must be excluded from a Terms of Use policy using this option. Administrators deploying device enrollment should not assume that one policy fits both initial enrollment and per-device acknowledgement; Microsoft treats those as separate scenarios.
The browser experience also matters. Microsoft warns that users who are not using per-device Terms of Use can be prompted at every sign-in in Microsoft Edge if their work profile is not synchronized. The practical fix is to have the user sign into and sync their work Edge profile, allowing single sign-on state to recognize the earlier acceptance. Without that preparation, a policy designed to be accepted once can generate repetitive prompts and a misleading perception that the system has lost consent.
The Safe Deployment Is Narrow Before It Is Broad
The video’s configuration path is a sound starting point, but production deployment needs a few controls around it:- Exclude emergency or break-glass administrator accounts so a misconfigured policy cannot lock out the people needed to repair it.
- Exclude service accounts and validate automated workflows separately, because they cannot interactively accept the document.
- Start with a pilot group and report-only analysis before enforcing the policy against a broad Microsoft 365 population.
- Decide whether the organization needs a fixed recurring date, a user-relative consent lifetime, or a new Terms of Use object for major revisions.
- Export acceptance evidence if retention requirements extend beyond the life of the Entra policy and its licensing state.