Enterprise applications can provide valuable integrations, but an approved application may also receive continuing access to Microsoft 365 mail, files, profiles, calendars, and other organizational data.
Why Application Consent Matters
Microsoft 365 users can connect third-party applications to Microsoft Entra. An application may request permission to read a profile, access files, read mail, manage calendars, or perform other actions.
Attackers can use malicious consent requests to obtain access without repeatedly signing in as the user. Legitimate applications can also become excessive, abandoned, or risky when permissions and ownership are not reviewed.
Understand the Main Objects
An application registration defines an application's identity and configuration. An enterprise application represents the application's service principal in the tenant and is used for assignments, permissions, sign-in, and access management.
A small business does not need to memorize every development detail, but administrators should know which object they are reviewing and which tenant permissions have been granted.
Application access can outlive the employee who approved it
Service principals, consent grants, secrets, certificates, and delegated access may remain after the original owner changes roles or leaves.
Inventory Enterprise Applications
Export or review enterprise applications, app registrations, service principals, integrated applications, single sign-on applications, and applications with consent grants.
Record the application name, publisher, verified-publisher status, owner, business purpose, assigned users or groups, permissions, consent type, credentials, last sign-in or use, and review date.
Understand Delegated Permissions
Delegated permissions allow an application to act on behalf of a signed-in user. The application's effective access is limited by both the granted permission and the user's own access.
Review whether the permission is necessary for the documented feature. A calendar application should not receive mail or file permissions without a clear requirement.
Understand Application Permissions
Application permissions allow an application or workload to act without a signed-in user. These permissions can provide broad tenant access and usually require administrator consent.
Review application permissions carefully, especially access to all mailboxes, files, directories, users, groups, or devices.
Application permissions can operate without a user session
Broad permissions should have documented ownership, technical justification, credential protection, monitoring, and recurring review.
Configure User Consent
Microsoft Entra allows administrators to control when users can grant permissions to applications. Microsoft recommends limiting user consent to applications from verified publishers for selected low-impact permissions.
Decide whether users can consent, which permissions are considered low impact, and whether selected users or groups need a different process. Document the setting and the reason for it.
Use Verified Publishers as One Signal
Verified publisher status helps identify that an application publisher completed Microsoft's verification process. It does not prove that the application is appropriate for the business or that every requested permission is safe.
Review the vendor, contract, privacy terms, security history, data location, support, business owner, and exact permissions in addition to publisher verification.
Configure an Admin Consent Workflow
The admin consent workflow allows users to request approval when they cannot consent to an application. Designated reviewers receive requests and can evaluate the application.
Being named a reviewer does not automatically grant the privilege needed to approve every request. Assign the least-privilege roles required and define escalation for high-permission applications.
Define Application Review Criteria
Reviewers should confirm:
- The requesting employee and manager
- The business purpose
- The vendor and verified publisher status
- The permissions requested
- Whether permissions are delegated or application permissions
- The users or groups in scope
- The data accessed and stored
- Security, privacy, legal, and contractual requirements
- Available alternatives
- The owner and review date
Avoid Automatic Tenant-Wide Consent
Tenant-wide administrator consent can grant permissions for the entire organization. Use it only when the application requires broad access and the business has completed an appropriate review.
Where possible, assign the application only to approved users or groups and require assignment so access is controlled explicitly.
Review Who Can Grant Consent
Limit administrator roles capable of granting consent. Global Administrator is highly privileged and should not be the default application-review role.
Use the least-permission role supported for the task, separate administrator accounts, strong authentication, and retained approval evidence.
Review User and Group Assignments
Require assignment for applications that should be restricted to selected people. Use groups where they improve consistency and review group ownership.
Remove former employees, transferred employees, contractors, and users who no longer need the application.
Review Application Owners
Each application should have an active business owner and technical owner. Avoid relying on one developer, vendor contact, or former employee.
Owners should approve permissions, assignments, credentials, integration changes, incident response, and retirement.
Protect Secrets and Certificates
Application registrations may use client secrets or certificates to authenticate. Store credentials in an approved secret-management system and restrict who can retrieve them.
Track expiration, rotate credentials before they expire, prefer certificates or managed identities where appropriate, and remove old credentials after validation.
Review Service Principal Sign-Ins
Review sign-in activity for service principals and managed identities. Look for unfamiliar resources, unexpected internet addresses, unusual volume, failures followed by success, and activity after the application should have been retired.
Confirm log retention and whether critical application activity should be exported to a monitoring platform.
Review OAuth and Consent Grants
Review delegated permission grants and application permission grants. Confirm that every permission still supports a current business requirement.
Removing a user assignment may not remove the application's tenant consent or service principal. Review all connected objects during cleanup.
Use Conditional Access Where Applicable
Conditional Access can protect user sign-ins to enterprise applications. Workload identities and service principals require separate design and appropriate licensing where Conditional Access for workload identities is used.
Document which policies protect the application, which accounts are excluded, and how application failures are investigated.
Include Applications in Offboarding
Employee offboarding should review application assignments, app ownership, consent grants, development access, credentials, automation, and vendor portals.
Transfer ownership before disabling the employee when critical integrations depend on the account.
Remove Applications Safely
Before deleting an enterprise application or service principal, identify dependent users, automation, single sign-on, provisioning, credentials, and data exports.
Disable or restrict access first when appropriate, test the business impact, preserve evidence, revoke permissions, remove credentials, and then delete according to the approved plan.
Review Applications Quarterly
Review high-permission and unused applications at least quarterly. Identify applications without owners, no recent sign-ins, expired credentials, excessive permissions, inactive vendors, and broad tenant-wide consent.
Record retained applications, accepted risk, removals, and the next review date.
Respond to Suspicious Consent
- Identify the user and application.
- Review permissions and consent type.
- Disable or restrict the application when necessary.
- Revoke consent and sessions as appropriate.
- Review the user's sign-ins and authentication methods.
- Search for mailbox, file, and directory activity.
- Remove malicious rules, tokens, and credentials.
- Document the incident and corrective actions.
Application and Consent Security Checklist
- Inventory enterprise applications and app registrations.
- Identify delegated and application permissions.
- Limit user consent to an approved policy.
- Use verified publishers as one review signal.
- Configure an admin consent workflow.
- Require documented business and security review.
- Limit tenant-wide administrator consent.
- Assign applications to approved users and groups.
- Maintain active business and technical owners.
- Protect and rotate secrets and certificates.
- Review service principal sign-ins and consent grants.
- Include applications in quarterly review and offboarding.
Frequently Asked Questions
Is a verified publisher application automatically safe?
No. Verified publisher status is useful, but the organization must still review permissions, data access, business need, vendor security, and ownership.
What is the difference between delegated and application permissions?
Delegated permissions act on behalf of a signed-in user. Application permissions can allow a workload to act without a signed-in user.
Should users be allowed to consent to any application?
No. Configure an approved user-consent policy and use an administrator workflow for applications that require broader permissions.
When Professional Support Helps
Professional support can inventory applications, configure user and admin consent, review permissions, identify risky or unused integrations, protect credentials, and establish recurring reviews.
Need help applying this?
Implement Microsoft 365 security with confidence.
J3 Systems Group LLC can implement Conditional Access, email protection, emergency access, monitoring, application consent controls, and supporting security procedures.