Defender for Cloud: Azure DevOps organization stuck in "OnboardedByOtherConnector" after the original connector was deleted – how to release the orphaned binding?

Question

Defender for Cloud: Azure DevOps organization stuck in "OnboardedByOtherConnector" after the original connector was deleted – how to release the orphaned binding?

Tags: azure-defender-for-cloud, azure-devops, defender-for-devops

Setup

• Defender for Cloud with Defender CSPM (Standard) enabled on the subscription.
• One Azure DevOps organization in the tenant. It is not connected to any other Defender for Cloud connector in any subscription of the tenant.
• Prerequisites on the Azure DevOps side are met: the authorizing user is Project Collection Administrator (verified, membership via group), has Basic access level, and "Third-party application access via OAuth" is On. The "Microsoft Security DevOps" enterprise application is consented in the tenant.

Problem

Some time ago (more than 90 days, nothing left in the activity log) an Azure DevOps connector –

let's call it connector-old in resource group rg-old – was deleted. It looks like only the

Microsoft.Security/securityConnectors ARM resource was removed, and the organization binding

underneath it was never released.

Last week a new connector connector-new was created in another resource group, authorized by a

PCA user, autodiscovery enabled. It is reported Healthy (health report, no issues) and the portal

shows "Connected", but after 4+ days it has never discovered the organization, projects or

repositories. Its list of organizations is empty.

In Azure Resource Graph (securityresources table) the only azuredevopsorgs row in the

whole tenant still sits under the deleted connector:

/subscriptions/<sub>/resourceGroups/rg-old/providers/Microsoft.Security/securityConnectors/connector-old/devops/default/azureDevOpsOrgs/<org>

  type: microsoft.security/securityconnectors/devops/azuredevopsorgs

  properties.onboardingState: onboarded

  properties.provisioningStatusMessage: OK

  properties.provisioningStatusUpdateTimeUtc: still refreshed roughly twice a day (~03:12 and ~07:13 UTC)

So the backend still considers the organization onboarded to a connector that no longer exists,

and keeps refreshing that binding.

What I verified via the REST API (api-version 2024-04-01)

• POST .../connector-new/devops/default/listAvailableAzureDevOpsOrgs → [{ "name": "<org>", "properties": { "onboardingState": "OnboardedByOtherConnector" } }]
• GET .../connector-new/devops/default/azureDevOpsOrgs → []
• GET .../connector-new/devops/default/azureDevOpsOrgs/<org> → 404 NotFound
• GET .../connector-old/devops/default/azureDevOpsOrgs/<org> → 404 ParentResourceNotFound (ARM rejects the call because the parent connector resource is gone)

What I tried

1. Re-authorized connector-new with a PCA account. No change after several daily cycles.
2. Recreated a connector with the exact same name and resource group as the deleted one (connector-old in rg-old), hoping the backend would match the orphaned binding by path. The new resource got a different hierarchyIdentifier, listAvailableAzureDevOpsOrgs still returns OnboardedByOtherConnector, and its own organization list is empty. The orphaned row in Resource Graph is unchanged. So the binding seems to be keyed by the old connector's internal identifier, not by the ARM path.

I have not tried PUT .../azureDevOpsOrgs/<org> with onboardingState: Onboarded on the new

connector yet, nor deleting the recreated connector via the portal, because I would like to

understand the expected behaviour first rather than keep mutating the state.

Questions

1. Is there any supported way (API or portal) to release an organization binding whose parent connector no longer exists? The Azure DevOps Orgs operation group has no Delete, and every path under the deleted connector fails at ARM level with ParentResourceNotFound.
2. Does deleting the Microsoft.Security/securityConnectors resource directly (without deleting devops/default first, i.e. not via the Defender for Cloud "Environment settings" blade) leave the organization binding orphaned by design? If so, is this documented anywhere?
3. Would PUT .../connector-new/devops/default/azureDevOpsOrgs/<org> with {"properties":{"onboardingState":"Onboarded"}} be expected to take over an organization that is in OnboardedByOtherConnector state, or is that always rejected?
4. Is this something only Microsoft Support can clean up on the backend? If yes, is there a specific problem type in the support request form that routes to the DevOps security team?

Any pointers appreciated.