We inherited a legacy Azure pay-as-you-go subscription that was originally created and managed by a former employee. The payment method, billing profile name, billing contacts, and invoice recipients have all been moved to organizational ownership. Multiple active IT administrators are Owners on the subscription, billing account, and billing profile, and the subscription is operating normally.
However, the former employee still appears as a direct Owner on the subscription. When we try to remove that assignment, Azure returns: "CannotDeleteLastRbacAdminAssignment" — "Cannot delete the last RBAC admin assignment."
The former employee's Entra ID account is still enabled for now but may soon be disabled. We want to understand whether there is an underlying dependency involving the original subscription creator, account administrator, billing hierarchy, management group, or another ownership relationship that is not obvious in the portal.
Could disabling the account affect administration, billing, or application availability? Is there a safer way to remove the assignment before expanding the application across the organization? We would prefer not to use a billing-ownership transfer workflow unless it is genuinely required, since billing and administrative ownership have already been transitioned. What governance cleanup would you complete before a production rollout, and when would you escalate this to Microsoft Support?
5 Answers
Check the management-group scope as well as the subscription. A user who is still an Owner at that layer may be influencing what Azure considers a valid administrator, so remove any obsolete assignment there and add the current administrative identity directly at the appropriate scope. Also verify that the remaining Owners are active assignments, not just Privileged Identity Management eligible roles.
A Global Administrator can use Azure’s access-elevation process to obtain temporary User Access Administrator access at the root scope, then review and repair subscription RBAC assignments. This can help when normal portal permissions are insufficient, but it should be performed carefully, audited, and reversed afterward if it is only being used for recovery. Billing roles alone do not replace Azure RBAC permissions.
Try assigning Owner directly to a platform or administrative identity first, rather than relying only on inherited permissions. In some cases, Azure will not allow removal if the remaining access is only eligible, inherited through a management group, or otherwise not considered a valid direct RBAC administrator. Once a confirmed direct Owner exists, retry removing the former employee.
Having current Owners on the billing account and billing profile does not necessarily satisfy Azure subscription RBAC. Billing ownership and resource-access ownership are separate permission systems, so the error may be caused by the subscription’s RBAC state rather than a billing problem. Before disabling the former employee, document the current assignments, confirm at least one directly assigned active administrative identity, check management-group inheritance and eligible roles, and wait for Support if Azure still treats the old account as required.
This kind of portal error can require Microsoft Support to correct on the backend. Since the billing hierarchy and subscription already have active organizational administrators, opening a support case is a sensible next step. Ask them to check for any legacy account-administrator or subscription-creator relationship that is being treated as the final RBAC administrator.
I’ve opened a support request and am waiting for a response. I was mainly hoping someone had already identified whether this error comes from an MCA or account-administrator relationship.