A retired radar integration’s service principal still has Contributor on a production resource group, even though the team says the app registration lives in another tenant. What should the security engineer do first?
Select an answer to reveal the explanation.
Short Explanation
That radar ghost still has a badge to production. Kill sign-in, yank Contributor, and shred leftover secrets—don’t hide behind “the app is in another tenant.”
Full Explanation
A service principal that retains an Azure RBAC assignment can still act on resources in this tenant even when related app registration details span tenants. For a retired radar integration whose service principal still has Contributor on a production resource group, first disable sign-in for that service principal, remove its Azure role assignment on the production resource group, and delete unused credentials—containing blast radius before longer cleanup debates.
Ignoring the principal because credentials “live in another tenant” fails by concept: the local service principal and its role assignment authorize actions in this subscription. Raising Secure Score with Defender for Cloud inventory scanning while leaving the role assignment alone improves visibility but does not remove standing Contributor. Moving the entire resource group into a new management group fails because RBAC assignments move with the resources; a move does not strip a stale principal’s Contributor automatically.
Exam caveat: treat orphaned service principals with privileged Azure roles as active until sign-in is disabled and assignments are removed. Operational check: disable SP sign-in, remove Contributor from the production RG, delete unused secrets or certificates, confirm the principal can no longer change resources, and record the retirement in the municipal identity inventory.