12.2 Access Requests & Terms of Use

From package design to living requests

Section 12.1 built catalogs, access packages, and assignment policies. This section is the operational loop: request → approve (possibly multi-stage) → deliver → use → extend or expire, plus Terms of Use (ToU) so legal and security acceptance is recorded before access. SC-300 loves scenarios that mix “self-service package” with “manager then app owner must approve” and “accept ToU before the partner portal opens.”

/practice/azure-sc-300Practice questions with detailed explanations

My Access and the request experience

Eligible users open the My Access portal (often referenced as myaccess.microsoft.com in Microsoft documentation and training) to:

• Discover access packages they are allowed to request.
• Submit requests with business justification when required.
• Track pending requests and existing assignments.
• Request extensions when policy allows before expiration.
• Review access when they are designated reviewers (access reviews overlap).

Discovery depends on policy. If the user’s identity is outside the assignment policy’s requestor scope (wrong tenant, not in allowed group, not in connected org), the package will not appear as requestable—even if the package “exists” in the tenant.

Managing access requests

Happy path

1. User requests package (optional justification + ToU acceptance).
2. Policy evaluates auto-approve vs approval required.
3. Approvers complete stage(s).
4. Entitlement management delivers assignments: group membership, app assignment/role, SharePoint site access.
5. User signs in; Conditional Access and other controls still apply at authentication time.
6. Near expiration, user may request extension if allowed.
7. On expiry, denial, or admin removal, resources are revoked from the package assignment path.

Admin operations

Always prefer removing the package assignment (or letting it expire) over surgically deleting only one of three resources when the package is the system of record—partial manual cleanup causes drift.

Request states (conceptual)

Troubleshooting “I was approved but cannot open the app” is not only entitlement management: check app assignment, licensing, SharePoint sharing, guest redemption, and Conditional Access failure in sign-in logs.

Multi-stage approval

Multi-stage approval sequences decisions so no single rubber stamp grants high-value access.

Typical stage designs

Configuration ideas SC-300 expects you to reason about:

• Order matters — stage 2 does not run until stage 1 approves.
• Approver sets — specific users, groups, manager, or other supported sponsor targets.
• Justification — requestor must explain why access is needed.
• Timeouts — unanswered requests should not hang forever; policies can escalate, deny, or follow configured timeout behavior.
• Alternate approvers — coverage when primary is on leave.
• No approval only when risk is truly low (rare for external high-value packages).

Multi-stage vs single-stage vs auto-approve

Exam story: “Contractor requests Finance package; line manager confirms engagement; finance application owner confirms least-privilege app role” → two-stage approval, not auto-approve.

Extensions as a second control plane

Expiration without extension forces a conscious renewal. Best practice for external packages:

1. Short initial duration (for example 30–90 days).
2. Allow extension requests.
3. Require approval on extension (often same multi-stage or a simpler re-approval).
4. Optionally couple with access reviews so long-lived assignments face periodic attestation even between extension events.

Terms of Use (ToU) policies

Terms of Use are Microsoft Entra policies that present PDF/content for acceptable use, privacy, or legal conditions. Users must accept (and can be required to re-accept on a schedule) before access proceeds under the controls that reference the ToU.

Create and configure ToU (concepts)

1. Create a Terms of Use policy object in Entra (Identity Governance / Conditional Access related experiences depending on portal navigation).
2. Upload the PDF (or configured content) in required languages if multi-language is needed.
3. Configure options such as:
   • Require users to expand the terms / consent UI behaviors as offered.
   • Expire acceptances so users re-accept periodically (for example annually).
   • Record who accepted and when for audit.
4. Attach the ToU where enforcement is required:
   • Conditional Access grant control: Require terms of use.
   • Entitlement management access package assignment policy: require acceptance as part of requesting/receiving the package.

ToU + Conditional Access deep dive

From the Conditional Access chapter, Require terms of use is a grant control. A CA policy can:

• Target All users or selected groups/guests.
• Target specific cloud apps (for example a partner portal or All cloud apps).
• Grant access only if ToU is accepted (optionally combined with MFA, compliant device, etc. using require all / require one of).

Exam distinctions:

• ToU in CA does not put the user in a security group by itself—it blocks or allows the sign-in until acceptance.
• ToU on an access package is about completing the entitlement request path and recording acceptance in the governance workflow.
• Company branding is not ToU. A custom sign-in background is not legal acceptance.

ToU + entitlement management deep dive

When a package policy requires ToU:

1. Requestor opens the package request.
2. Must accept the configured Terms of Use.
3. Only then can the request proceed to approval/delivery per policy.
4. Acceptance is auditable—useful when compliance asks “did partners agree to the data handling terms?”

Design tips:

• Use a partner-specific ToU on external packages rather than relying only on a generic employee ToU.
• Re-expire acceptances when legal language changes materially.
• Do not assume ToU replaces DLP, sensitivity labels, or CA device controls—it is an acceptance gate, not data protection.

How the pieces stack in Zero Trust

A realistic partner access stack:

1. Connected organization defines which external tenant/domain is in scope (section 12.3).
2. Access package grants least-privilege group/app/site membership after multi-stage approval.
3. Package ToU records project-specific acceptance.
4. Conditional Access requires MFA / authentication strength / device / session controls for guests on those apps.
5. CA ToU (optional) enforces org-wide legal terms at sign-in.
6. Expiration + access reviews remove stale access; guest lifecycle settings clean directory objects when appropriate.

If an exam answer only enables ToU branding or only creates a PDF without binding it to CA or a package policy, it is incomplete.

Monitoring and audit cues

Identity admins should be able to answer:

• Who requested which package and when?
• Which approver approved stage 1 vs stage 2?
• Did the user accept ToU version X?
• When did the assignment expire and were resources removed?
• Why is a request still pending (approver inactive)?

Use audit logs, entitlement management reporting experiences, and request history in the admin center. For sign-in failures after delivery, pivot to sign-in logs and Conditional Access results—not only the package blade.

Exam traps

• Thinking My Access requests bypass Conditional Access after approval.
• Auto-approving high-risk external packages “to reduce tickets.”
• Confusing ToU grant in CA with access package resource assignment.
• Single Global Administrator as the only approver for every package (operational bottleneck and poor separation of duties).
• Forgetting extensions without approval recreate permanent access in slow motion.

Summary of section 12.2

/practice/azure-sc-300Practice questions with detailed explanations