Entra terms of use: require acceptance through Conditional Access

What Entra terms of use actually enforce

Entra terms of use present a document during an interactive sign-in and can make acceptance a condition of access. The useful question is whether the intended people must accept the approved document before reaching the intended application. Finding a PDF in the tenant answers only part of that question.

Start with a business requirement: who needs to acknowledge which rules, for which resources, and who owns the text? Ask the appropriate business and legal reviewers to approve the document before configuring enforcement. An absent agreement is a configuration signal to investigate, not proof of a universal regulatory violation. Some tenants may have no justified use case for this feature; record that decision rather than creating an empty agreement to clear a finding.

A practical pilot might cover a partner workspace whose owner wants external collaborators to acknowledge its handling rules. Define the population and application explicitly. Do not assume that every external sharing path creates an Entra guest account or passes through the same sign-in journey. Use the guest Conditional Access and external collaboration review to frame that population and its exclusions before adding document acceptance.

The deployment should produce evidence for three separate questions: does the agreement exist, does an enforcing policy require it for the chosen population and resource, and do user responses show the expected document was accepted or declined? Keep those answers separate in the change record.

How the agreement and Conditional Access fit together

Microsoft's terms of use setup guide requires Entra ID P1 licensing and a PDF. It lists Security Reader as the minimum role for reading configuration and Conditional Access Administrator for creating or modifying it. Confirm the subscription and the administrator's assignment before scheduling the pilot.

The agreement holds document settings; a Conditional Access grant connects it to access decisions. Language and version choices also belong in the design. An agreement that exists without the intended policy attachment can satisfy an existence check while leaving the business requirement unmet.

The Graph agreement resource exposes an identifier, viewing and per-device requirements, an expiration schedule, and a per-user reacceptance duration. Its file relationship identifies the default PDF; files is documented as being deprecated in favor of file. The acceptances relationship is a separate collection of user responses.

Use these distinctions when planning evidence. Keep the agreement ID and approved PDF version together, then record the policy that requires that agreement. A display name is convenient for people, but the identifier is the safer join key for configuration and response records. Assign an owner to maintain the document and translations, and a policy owner to maintain scope. If either changes, review the other side of the connection.

Detection: check existence, attachment, and responses separately

Inventory the agreements without confusing a failed read with absence

In the Entra admin center, open Entra ID > Conditional Access > Terms of use. Identify the agreement intended for the business scenario, its document languages and its version history. If the page is empty, verify that you are inspecting the correct tenant with an appropriate reading role before recording absence.

For an independent API inventory, Microsoft documents this request in List agreements:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements
Authorization: Bearer {token}

This is a documented request template, not a query executed against a customer tenant for this article. The page lists delegated Agreement.Read.All for work or school accounts, with Security Reader as the least privileged supported role. It lists application permissions as unsupported for this operation. Check the current permission model for the client you use instead of assuming an application token and a delegated token provide equivalent coverage.

Treat an authorization error, interrupted collection or unreadable response as an unresolved observation. Only a successful, complete inventory supports the conclusion that no agreements were returned. Preserve the tenant context, collection time and any errors with the result.

Inspect the policy that should require the agreement

Open the relevant Conditional Access policy and inspect its state, included users or groups, exclusions, target resources and grant controls. Confirm that the intended agreement is selected under Grant access, providing the Require terms of use requirement. Check the combination of grant controls so the planned access decision actually requires acceptance.

A policy name mentioning terms of use is insufficient evidence. Report-only configuration is useful for reviewing impact, but the enforcement test must use an enabled pilot policy. Trace an intended test user through the assignments and exclusions, then exercise the resource sign-in. If the agreement inventory contains entries but no intended policy selects them, record an attachment gap separately from agreement absence.

Review acceptance evidence for the intended version

The portal exposes accepted and declined responses and version history. For API evidence, List acceptances documents:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements/{agreementsId}/acceptances
Authorization: Bearer {token}

The returned objects are agreementAcceptance records, commonly referred to as agreement acceptances. The resource reference describes agreementId, agreementFileId, userId, state, recordedDateTime and expirationDateTime. The documented response states are accepted and declined. Correlate the user, agreement and file instead of treating any historical acceptance as evidence for the current document.

For this agreement-scoped endpoint, the list operation documents delegated AgreementAcceptance.Read and the higher permission AgreementAcceptance.Read.All, with Security Reader as the least privileged supported role. It lists application permissions as unsupported. Handle acceptance exports as user data, limit access to the reviewers who need it, and follow your organization's retention rules. The purpose of the export is to substantiate the pilot, not to create an unrestricted copy of user activity.

Remediation: deploy an approved agreement through a scoped pilot

1. Approve the text and define the acceptance requirement

Write down the resource owner, document owner, intended users, required languages, exceptions and expected reacceptance behavior. Resolve whether an updated version requires a new response. Give support staff a contact for questions about the terms and a separate contact for sign-in problems. Do this before uploading the PDF so an authentication change does not become an improvised policy-writing exercise.

2. Create the agreement and verify its presentation

Use Conditional Access > Terms of use > New terms. Upload the finalized PDF, choose its language and user-facing title, and configure Require users to expand the terms of use when the approved experience requires opening the document before acceptance. Add the approved language variants and review what an intended user sees. Record the agreement ID and which PDF was uploaded for each language.

Decide on expiration and per-device options from the use case rather than enabling them automatically. In particular, Learn excludes B2B users from per-device terms of use support. For an external-user pilot, keep the ordinary agreement requirement distinct from that per-device option and validate the actual collaboration journey.

3. Attach the agreement to the intended Conditional Access grant

Microsoft's example policy selects the created terms under Access controls > Grant > Grant access, starts in Report-only, and moves to On after reviewing impact. Its example targets Microsoft Admin Portals; adapt the resource assignment to your approved scenario instead of copying that target into an unrelated workspace pilot.

Start with the intended pilot group and resource. Preserve emergency recovery access and document exclusions. Learn also warns that service accounts cannot satisfy this interactive acceptance requirement; identify such dependencies before enabling enforcement. Review report-only impact first, then enable the pilot for the interactive tests. An impact review and an enforced acceptance test answer different questions, so retain both.

4. Test acceptance, refusal, and the excluded recovery path

Use test identities representing the intended population. For the acceptance path, enter the target resource through its normal sign-in route, check the displayed PDF and language, expand it if required, accept it, and verify resource access. For the refusal path, use an identity without a prior acceptance and verify that declining prevents access. Keep these as expected test outcomes until you have observed and recorded them.

Check the acceptance records against the test user and file ID. Also verify that the planned recovery account remains outside the pilot policy. If an intended user receives no prompt, investigate existing acceptance, session state, assignments, exclusions and the resource selected in the policy. Do not immediately conclude that the agreement is broken or that the user is covered correctly.

5. Maintain versions and test when reacceptance occurs

Review Edit terms, update the PDF for the relevant language and make an explicit Require reaccept decision. Preserve the previous evidence before changing the document, then verify the response record for the new file. Treat localized PDFs as managed versions of the same approved message; a revised English document should trigger review of its other language variants.

Require reaccept is not an instant interruption of an active session. Learn says existing sessions must expire before the new acceptance requirement is presented. Plan verification around the next relevant sign-in or session evaluation, and record that context with the observed prompt. The session controls and sign-in frequency guide explains why an access policy and the moment a session is evaluated must be considered together. Do not promise an immediate tenant-wide reacceptance deadline solely because a PDF was updated.

6. Record evidence and hand over maintenance

Keep the approved text reference, agreement and policy identifiers, scope, exclusions, PDF versions and observed pilot results in the change record. Record failures and unresolved paths as well as successes. Expand the policy only after the owners accept the evidence and support implications. Arrange a review when the document, application population or collaboration model changes; the agreement inventory alone will not reveal drift in those relationships.

How EtcSec Detects This

The etc-collector AZ_NO_TERMS_OF_USE detector reads AzureTermsOfUseProbed and AzureTermsOfUseCount. Its Detect() implementation has three branches:

Count 1 is the finding's count; it is not a count of unaccepted users. The unprobed branch is neither an absence result nor a compliance verdict. A failed collection must remain visible until it can be investigated.

This check establishes agreement existence only. It does not validate Conditional Access attachment, enabled policy state, targeting, exceptions, PDF quality, language coverage or user acceptances. Creating an unused agreement can remove this particular finding without enforcing the business requirement. Pair the collector result with the policy inspection and acceptance evidence above, and retain an explicit suitability decision when terms of use are unnecessary for the tenant.