A weekend review shows a gallery CRM still holds a tenant-wide Mail.ReadWrite OAuth grant from a pilot last year. What should the security engineer do in this tenant?
Select an answer to reveal the explanation.
Short Explanation
That leftover Mail.ReadWrite grant is a master key you forgot under the mat. Revoke it on the enterprise app in your tenant—you do not need (or get) permission to delete the vendor’s app registration in their directory.
Full Explanation
OAuth permission grants on an enterprise application represent consented Graph or API permissions in this tenant. When a gallery CRM still holds a tenant-wide Mail.ReadWrite grant from an old pilot, the security engineer should revoke that OAuth permission grant on the CRM enterprise application in this tenant so the CRM can no longer read/write mail with the stale consent.
Deleting the CRM app registration from the vendor’s home tenant fails: customers do not administer the vendor’s home application object as the remediation for their own tenant’s grant. Writing a Sentinel hunting query and leaving the permission until the next audit fails because detection without revocation leaves the grant active. Editing MSAL sample code in a Function App fails by concept: client code samples do not remove a tenant-wide admin/user consent grant already recorded on the enterprise application.
Exam caveat: review enterprise application permissions regularly; tenant-wide mail grants are high impact even on “temporary” pilots. Operational check: open the CRM enterprise application’s permissions/grants, revoke Mail.ReadWrite, confirm Graph calls requiring that grant fail, and document whether any still-needed narrower scope should be re-consented deliberately.