User and admin consent
Controls whether an application can receive delegated or application permissions and who is authorized to approve the requested scope.
Microsoft 365 privileged access governance
Microsoft 365 Support Access and Admin Consent Governance Guide
Control application consent, enterprise app permissions, partner GDAP relationships, administrator approval powers, Microsoft support data-access requests, monitoring, expiration, and revocation as separate access paths with one evidence standard.
Admin consentEnterprise appsPartner GDAPCustomer LockboxRevocation evidence
Governance objective
Do not collapse five different access paths into “vendor access”
An OAuth consent grant, an enterprise application assignment, a partner’s GDAP relationship, an administrator role, and a Microsoft Customer Lockbox request are not interchangeable. They use different identities, approval mechanisms, scopes, time limits, logs, and revocation methods. Each needs a named owner and a reproducible decision record.
Enterprise applications
Controls the service principal, permissions, assignments, owners, sign-in behavior, credentials, Conditional Access exposure, and tenant lifecycle.
Partner delegated access
Controls which partner security groups receive which GDAP roles, for which customer, for how long, and whether auto-extend is justified.
Administrator roles
Controls who can configure the workflow, review requests, grant consent, manage applications, create support requests, or approve data access.
Microsoft support data access
Customer Lockbox can require an organizational approval before a Microsoft engineer receives time-limited access to supported customer content.
Monitoring and removal
Audit evidence must show grants, changes, sign-ins, service-principal activity, partner relationships, approvals, expirations, denials, and revocation.
Decision rule: approval is not complete until the organization can state exactly who or what receives access, which resources and actions are allowed, whether a user must be present, when access ends, how activity is detected, and how access is removed.
Access decision matrix
Identify the principal, permission model, and revocation object
| Access path | Principal and scope | Approval questions | Evidence and removal |
|---|---|---|---|
| Delegated OAuth permission | The app acts on behalf of a signed-in user and is constrained by both the granted permission and that user’s effective access. | Is user presence required? Is the scope necessary? Can user consent be limited to low-risk permissions and verified publishers? | Consent grant, app/publisher, scope, users, owner, sign-in evidence; revoke delegated grants and invalidate relevant sessions/tokens when required. |
| Application permission | The app acts as itself without a signed-in user and can operate across the tenant resources allowed by the permission. | Why is unattended access necessary? Is resource-specific scoping available? Who protects credentials/certificates and monitors use? | App role grants, credential inventory, resource restriction, owner, workload logs; remove app role assignment/credential or disable/delete the service principal. |
| Enterprise app assignment | Users/groups are assigned to use an enterprise application; assignment does not by itself replace permission review. | Is assignment required? Are owners active? Is access conditional, licensed, and periodically reviewed? | Assignments, owners, sign-ins, Conditional Access, provisioning state; unassign, disable sign-in, remove provisioning, or retire the service principal. |
| GDAP relationship | Partner users inherit approved customer roles through partner security-group access assignments. | Are roles least privilege and task-specific? Is duration appropriate? Is auto-extend justified? Are partner memberships controlled? | Relationship, roles, groups, users, duration, customer approval, access-assignment evidence; remove roles, terminate relationship, or remove partner users from groups. |
| Customer Lockbox | A Microsoft engineer receives approved, temporary access to customer content for a specific support request. | Does the service request require content access? Is the request number valid? Are scope, reason, and timing acceptable? | Request, approver, decision, service request, duration, email/history, audit records; deny or allow the approved period to expire. |
Admin consent workflow
Configure a request path without assuming every reviewer can approve
Workflow configuration controls
- Document who can submit requests and the user guidance shown when consent is blocked.
- Assign reviewers by named users, groups, or roles and protect reviewer membership.
- Set request expiration, notifications, reminders, and an operational mailbox or queue owner.
- Record when the workflow was enabled; Microsoft notes that activation can take up to an hour.
- Review pending and expired requests, denials, blocks, and request-volume trends.
Reviewer authority controls
- Being designated as a reviewer does not elevate the person’s Microsoft Entra permissions.
- A reviewer can act only within the consent authority of the roles already assigned.
- Microsoft documents that only Global Administrators can approve requests for Microsoft Graph application permissions.
- Cloud Application Administrator or another suitable role may review and act on other requests, subject to permission sensitivity.
- Separate technical approval authority from the business/security decision and preserve both.
Approve, deny, or block: a denial resolves the current request but allows future requests. Blocking also prevents future requests for that application and creates a disabled service principal. Record the rationale and the expected reconsideration path.
Eight-stage review
Evaluate the application before granting tenant-wide consent
Do not approve from the permission prompt alone. Use the app details, requested-by context, enterprise application record, publisher information, requested permissions, data path, authentication design, and business owner.
Identify
Capture application ID, service principal ID, tenant, publisher, verified-publisher status, requester, business owner, and support owner.
Classify
Separate delegated permissions, application permissions, role assignments, resource-specific consent, and other access methods.
Justify
Map each permission to a documented feature and data flow. Reject “required by vendor” as the only rationale.
Reduce
Remove unused scopes, prefer delegated or resource-specific access where appropriate, restrict assignments, and limit credentials.
Validate
Review publisher/domain, privacy/security terms, data location, retention, subprocessors, incident notification, and removal support.
Approve safely
Use the correct privileged role, record the approver, grant only the reviewed scope, and avoid unrelated changes.
Monitor
Review sign-ins, service-principal activity, consent/app-role changes, credentials, assignments, risky behavior, and owner status.
Recertify or remove
At the review date, validate use and permissions again or revoke grants, disable access, remove credentials, and close dependencies.
Partner support access
Design GDAP around workload tasks, security groups, and an end date
Relationship scope
- Customer and partner tenant identifiers
- Business service and supported workloads
- Requested Microsoft Entra roles
- Start/end date and maximum two-year limit
- Auto-extend decision and owner
Partner assignment
- Partner security groups assigned to roles
- Named partner users and role purpose
- MFA/Conditional Access considerations
- Joiner/mover/leaver process
- Emergency elevation procedure
Customer evidence
- Customer approval and relationship export
- Role-to-task mapping and exceptions
- Partner relationship review
- Activity/support-ticket evidence
- Removal or termination validation
Current GDAP constraints: permanent relationships are not supported; the documented maximum duration is two years. Auto-extend adds six months until disabled or terminated, but a relationship containing Global Administrator cannot auto-extend. Service Support Administrator is the documented least-privileged partner role for creating customer support tickets.
Microsoft support data access
Connect Customer Lockbox decisions to the support case and audit log
Approval checklist
- Confirm the related Microsoft 365 service request number and requesting team.
- Understand which supported service and customer content require access.
- Use Global Administrator only if necessary; prefer the Customer Lockbox access approver role.
- Verify the request is still valid, the scope matches the case, and the incident owner understands the decision.
- Approve or deny within the documented request window and retain the justification.
Timing and evidence
- Microsoft documents a default 12-hour response window before a request expires.
- Approved engineer access is currently valid for no more than four hours and can be shorter.
- Request decisions and engineer actions are recorded in Microsoft 365 audit data.
- Cross-reference email notices, Lockbox request history, support case activity, and audit records.
- Review licensing and supported services before relying on Customer Lockbox as a control.
Monitoring and removal
Prove that approved access remains necessary and removable
Application signals
- Consent and app-role grants
- Service-principal and credential changes
- Interactive/non-interactive sign-ins
- Assignment and owner changes
- Unusual resource access and failed activity
Partner and role signals
- GDAP relationships and expiration
- Auto-extend state and role changes
- Partner group membership
- Administrator role assignment changes
- Support requests created on behalf of customer
Removal validation
- Revoke delegated/app permission grants
- Remove assignments and credentials
- Disable/delete stale service principals
- Terminate partner role/relationship access
- Test that prior access no longer succeeds
Token warning: changing a portal setting does not always terminate every active token or downstream session immediately. Include token invalidation, credential removal, application-side access, and a failed-access test in the closure plan.
Common failure modes
Find excessive or orphaned access before an incident
Prompt-only approval
An administrator approves from the consent prompt without reviewing publisher, business owner, data flow, application permissions, or revocation design.
Application permission treated as user access
Unattended app-only access is underestimated because reviewers assume the signed-in user’s permissions constrain it.
Reviewer role assumption
A person is added as a workflow reviewer but lacks—or is over-granted—the role required for the requested permission.
Orphaned enterprise app
Owners leave, credentials remain, sign-in activity is poorly understood, and no business team accepts removal risk.
Broad partner relationship
GDAP requests many roles “just in case,” uses long duration or auto-extend without review, and lacks partner membership evidence.
Support access mixed with consent
A Microsoft engineer’s Lockbox request, a CSP relationship, and an enterprise app grant are recorded as one generic vendor-access item.
Denial without closure
The request is denied, but the requester receives no safe alternative, app owner remediation path, or decision rationale.
Removal without test
A grant or relationship is removed in one portal, but credentials, tokens, app assignments, or downstream sessions still work.
No recurring evidence
The organization has a one-time approval ticket but no owner attestation, activity review, expiration, exception register, or removal result.
Audit-ready evidence
Retain a decision package for every high-impact grant
Request and decision
- Requester, business owner, security reviewer
- App/partner/support identity
- Permission or role summary
- Rationale, alternatives, approve/deny/block
- Approver authority and date
Technical state
- Service principal and publisher
- Delegated/application grants
- Assignments, roles, groups, credentials
- GDAP or Lockbox scope/duration
- Monitoring query and alert ownership
Lifecycle closure
- Review/expiration date
- Usage and owner attestation
- Exception and residual risk
- Revocation/termination actions
- Failed-access validation and final status
Related ecosystem guides
Continue into application, role, and tenant governance
Authoritative Microsoft references
FAQ
Microsoft 365 support access and admin consent FAQ
What is the difference between delegated and application permissions?
Delegated permissions let an app act on behalf of a signed-in user and are constrained by the user’s effective access. Application permissions let an app act as itself without a signed-in user and can support unattended tenant-wide operations, so they usually need stronger review.
Does being an admin consent reviewer allow someone to approve every request?
No. Reviewer designation does not elevate Microsoft Entra permissions. The reviewer must already hold a role authorized to grant the requested permissions, and Microsoft documents Global Administrator approval for Microsoft Graph application-permission requests.
What is the difference between denying and blocking a consent request?
Denying rejects the current request but allows future requests. Blocking also prevents future requests for the same application and creates a disabled service principal in the tenant.
How long can a GDAP relationship last?
Microsoft documents a maximum two-year duration. Auto-extend can add six months repeatedly until disabled or terminated, but relationships containing Global Administrator cannot auto-extend.
What does Customer Lockbox approve?
For supported Microsoft 365 services and licensing, it lets an organization approve or deny a specific, time-limited request by a Microsoft engineer to access customer content for a support scenario. It is separate from app consent and partner GDAP.
What evidence should be kept when access is removed?
Keep the original grant, owner and review decision, removal actions across grants/roles/assignments/credentials, token or session handling, audit events, and a validation showing that the prior access no longer succeeds.
Turn support and consent decisions into controlled, reviewable access
IT Perfection helps Orange County and Southern California organizations inventory enterprise apps, improve consent workflows, scope partner support access, document Customer Lockbox decisions, monitor activity, and remove stale access.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience. This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Microsoft roles, licensing, portal behavior, limits, and supported workloads change; validate current Microsoft documentation and tenant behavior before implementation.
