The incident was caused by an employment-status change that kept a worker’s Microsoft Entra ID account active for legitimate vendor collaboration while failing to remove a direct Azure Owner role inherited by production subscriptions. This azure offboarding incident postmortem found that the technical gap was enabled by a broader control failure: responsibilities after a change of employment were neither fully defined in the HR-to-IAM workflow nor verified by the managers accountable for access removal.
This is a composite incident based on recurring audit and operational patterns. It is written for IT managers who need to explain not only what happened, but also how the organization can demonstrate effective remediation against ISO 27001 control 6.5, Responsibilities After Termination or Change of Employment.
What happened during the Azure access incident?
A senior cloud operations engineer moved from an internal operations role to a role with an outsourced application-support provider. The individual still required a corporate identity, Microsoft Teams access, and limited access to a non-production support subscription. However, the role change did not require continued administrative access to the Azure production management group.
Before the transfer, the engineer had received a direct Owner role assignment at the mg-platform-prod management-group scope during an urgent migration. The assignment was intended to be temporary, but it had not been converted to a time-bound Privileged Identity Management (PIM) assignment. When the worker’s employment classification changed, the HR event triggered collaboration-access provisioning but did not initiate a privileged-access recertification or remove direct Azure role assignments.
What was the timeline of the azure offboarding incident postmortem?
| Time (UTC) | Event | Control outcome |
|---|---|---|
| Monday, 09:12 | HR records the employee’s internal-role end date and new vendor-sponsored support assignment in Workday. | The event is categorized as a contingent-worker conversion, not as a change requiring privileged-access removal. |
| Monday, 10:04 | Identity workflow updates the worker’s Entra ID attributes and retains the account for Teams and vendor collaboration. | Account remains enabled as intended; no Azure RBAC review task is created. |
| Tuesday, 08:30 | The former operations manager approves the departmental transfer in the service-management tool. | The approval form lists applications and groups, but not direct Azure role assignments or management-group inheritance. |
| Thursday, 14:17 | The worker signs in from the vendor-managed device using existing MFA registration and accesses the Azure portal. | Conditional Access permits access because the account is active and meets the vendor collaboration policy. |
| Thursday, 14:26 | The worker opens a production Key Vault while troubleshooting an application integration and retrieves a connection-string secret. | Azure Key Vault diagnostic logs record the secret retrieval; no alert is configured for access by transitioned personnel. |
| Friday, 09:42 | Security Operations identifies an unusual Key Vault secret-read event during a manual review of Microsoft Sentinel logs. | Incident declared; account sessions revoked and Azure RBAC assignments removed. |
| Friday, 13:15 | Investigation confirms no resource deployment, deletion, or further secret access occurred. | Exposed secret is rotated, and affected application credentials are reissued. |
The worker reported that the access was used to investigate an application issue, not to bypass controls. That reduced the likelihood of malicious intent, but it did not reduce the incident’s significance. Production secrets were available to a person whose business role no longer justified access, creating a confidentiality issue and an audit finding risk.
What did the root cause analysis identify?
The immediate cause was a direct Azure RBAC assignment that survived the worker’s role change. The deeper cause was that the organization treated “offboarding” as account disablement only. It did not treat a change of employment, reporting line, contractual status, or job function as an event requiring review of access and continuing security obligations.
| Finding | Evidence | Root-cause conclusion |
|---|---|---|
| Direct production privilege remained assigned | Azure Activity Log showed Microsoft.Authorization/roleAssignments/write assigning Owner at management-group scope 11 months earlier. |
Emergency access was granted without an expiry date, PIM eligibility, or formal removal owner. |
| HR event did not create an IAM deprovisioning task | Workday-to-ServiceNow mapping categorized the event as “supplier conversion.” | Workflow logic was designed around termination, not all material changes of employment. |
| Manager review omitted Azure RBAC | Transfer checklist covered shared mailboxes, VPN, and application groups only. | Control ownership was fragmented between HR, IT service management, and the cloud platform team. |
| Detection occurred after secret access | Sentinel had Key Vault logging but no analytic rule correlated role changes with sensitive secret reads. | Logging existed, but monitoring use cases did not address transition-related access risk. |
The investigation also found that the worker’s Owner role was direct rather than group-based. Group-based assignments were included in quarterly access reviews; direct assignments at management-group scope were exported separately and were not included in the manager attestation package. This design choice made the Azure offboarding failure difficult to see even though the relevant data existed.
Why did ISO 27001 control 6.5 fail in practice?
ISO 27001 control 6.5 requires that information security responsibilities and duties that remain valid after termination or change of employment be defined, enforced, and communicated to relevant personnel and other interested parties.[1] The organization had a termination procedure, but the procedure did not adequately cover changes in employment status or role. It also did not distinguish between access that should continue for collaboration and privileged access that must be removed, reapproved, or converted to time-bound access.
Three control assumptions failed at once. First, HR assumed the identity workflow would notify technical owners of any meaningful status change. Second, the cloud team assumed managers would identify inappropriate access during transfers. Third, managers assumed Azure privileged access was automatically tied to the employee’s prior department. None of those assumptions was documented as an enforceable control requirement.
The communication component of control 6.5 was equally weak. The worker received a welcome package for the new vendor-support role, but no written notice stated which security duties continued, which production access was prohibited, how to report residual access, or that existing administrative roles would be revoked. The former manager and vendor relationship owner were not required to attest that those expectations had been communicated.
What corrective and preventive actions were taken?
Containment began with revoking the worker’s Entra ID refresh tokens, removing all Azure role assignments, rotating the accessed Key Vault secret, and reviewing Activity Logs, Key Vault diagnostic logs, Microsoft Entra sign-in logs, and Defender for Cloud alerts for the preceding 30 days. The affected subscription was reviewed for deployments, role changes, service-principal credential creation, and data-access events. No further unauthorized activity was identified.
The remediation program focused on making employment changes measurable control events rather than relying on informal manager judgment.
- Direct privilege remediation: The cloud platform team removed standing
Ownerassignments from users at management-group scope. Administrative access now uses Entra ID security groups and PIM eligible assignments with eight-hour activation windows, justification, MFA, and ticket-number requirements. - Workflow correction: Workday events for department changes, manager changes, internal-to-vendor transfers, contractor conversions, and termination now create a ServiceNow access-review task. The task is not closed until application owners and the Azure platform owner attest to retain, remove, or reapprove access.
- Azure-specific evidence: A weekly job exports management-group, subscription, resource-group, and resource-level assignments from Azure Resource Graph. It identifies direct user assignments, inherited privileges, and assignments outside approved Entra groups.
- Communication and accountability: HR issues a transition notice describing continuing confidentiality, acceptable-use, incident-reporting, and access-return responsibilities. The receiving manager, departing manager, and vendor relationship owner each acknowledge their responsibilities.
- Detection improvement: Microsoft Sentinel now alerts when a user with an employment-status change in the previous 30 days reads a production Key Vault secret, activates a PIM role, or performs a privileged Azure Resource Manager operation.
The following validation query became part of the cloud team’s evidence pack for monthly control testing:
az role assignment list --all \
--query "[?principalType=='User' && roleDefinitionName=='Owner'].{
principal:principalName,
scope:scope,
role:roleDefinitionName
}" \
--output tableThe command is not, by itself, proof of compliance. The evidence package also includes the HR event identifier, ServiceNow review record, manager attestation, PIM activation history, removal timestamp, and any approved exception with an expiry date. That combination gives an auditor a traceable link from personnel change to access decision and technical enforcement.
What lessons generalize from this Azure role-removal failure?
First, offboarding is a lifecycle process, not a synonym for disabling an account. Any event that changes a person’s authority, employer, manager, location, or contractual relationship should be assessed for access impact. This is especially important in Azure, where an active Entra ID account may be entirely appropriate while inherited management-group permissions are not.
Second, privileged access should have a technical end date whenever possible. The incident would likely have been prevented if the original migration access had been granted through PIM as eligible access rather than a standing direct Owner assignment. Emergency exceptions are often necessary; permanent emergency access is usually a control debt.
Third, audit-ready controls require evidence across organizational boundaries. HR owns the status change, managers own business justification, IAM owns workflow execution, and the cloud team owns Azure RBAC enforcement. A certification audit will test whether those responsibilities are connected, communicated, and demonstrably performed—not whether each team has a separate procedure.
Finally, monitoring should focus on meaningful combinations of events. A Key Vault secret read is not automatically suspicious, and a role change is not automatically suspicious. A secret read by a recently transitioned worker with residual production privilege is a high-value correlation that turns an Azure transition-access incident into a detectable event.
Next step: Before your next ISO 27001 audit, run a documented review of every direct Azure RBAC assignment associated with personnel who changed roles, managers, or employment status during the last 90 days.
