AWS Security Hub Can See Azure Now. Can Your Operating Model?

The multicloud security problem was never a shortage of dashboards. It was the absence of a common answer to a basic operational question: when an exposed Azure function and an over-permissioned AWS role both land in the queue, which one can reach something that matters first?

In July, AWS moved into that decision layer. Security Hub can now connect to a Microsoft Entra tenant, discover selected Azure compute and identity resources, evaluate them for configuration, exposure, and vulnerability issues, and place the findings beside AWS findings in the same service. AWS says Azure resources are assessed against the CIS Microsoft Azure Foundations Benchmark and its Azure Foundational Best Practices standard, using the same finding format and response workflows as AWS resources.

The launch is important because it makes one queue technically possible. It does not make the risks equivalent by default. A common schema can normalize fields; it cannot normalize business context, identity semantics, telemetry gaps, or ownership. The security program still has to build those translations, and it has to do so without erasing where each piece of evidence came from.

What the connector actually covers

At launch, Security Hub discovers Azure virtual machines, container images, Function Apps, and identities. It evaluates resource configuration through Security Hub CSPM, analyzes internet exposure, and reports software vulnerabilities. The setup process automatically enables CIS Microsoft Azure Foundations Benchmark version 4.0 and an Azure Foundational Best Practices standard for the connected scope.

The connector is not a magical API key. AWS’s documented setup establishes a federated identity between AWS and Microsoft Entra, configures permissions at the Azure tenant or management-group scope, and uses Azure Activity Logs for change-driven discovery. The person bootstrapping it needs unusually broad Azure privileges because the workflow registers an application, grants Microsoft Graph consent, assigns role-based access, and configures Entra audit diagnostics. That initial privilege should be treated as a controlled ceremony, not a help-desk task.

AWS says findings can begin within 15 to 30 minutes for resources with Activity Log events, while a complete evaluation of existing resources can take up to 24 hours. That creates an immediate operational rule: connector creation time is not coverage time. Until the baseline completes, absence of findings is not evidence of absence.

A common format is necessary and insufficient

Putting findings into a common schema removes expensive plumbing. Severity, resource, control, workflow state, and remediation fields can be searched and automated consistently. The SOC no longer needs a separate routing system merely because one asset begins with an Azure resource ID and another with an ARN.

But the same severity does not guarantee the same risk. A public virtual machine in an Azure development subscription may be intentional and isolated. A nominally private EC2 instance may carry an IAM role that can read the production secrets account. Cloud-native identity, network, and organizational boundaries differ enough that a normalized finding needs a second layer: reachability, privilege path, business criticality, and data sensitivity.

Use Security Hub as the common work surface, not the sole source of truth. Every case should retain the original provider, tenant or organization, subscription or account, native resource identifier, observed timestamp, control version, and connector health at time of evaluation. If an analyst must cross-check the issue in Azure, the case should contain the exact coordinates to do it.

The connector is itself a tier-zero dependency

A cross-cloud security platform can only report what its connector is permitted and able to see. That makes connector health part of the detection system. Monitor degraded status, permission drift, diagnostic-setting changes, stale last-seen timestamps, sudden asset-count drops, and unexpected narrowing of management-group scope.

Create an independent control in Azure that alerts when the enterprise application, federated credential, Graph consent, or assigned roles change. If the only alarm for a broken connector is delivered through the broken connector, the architecture contains a circular dependency.

The federated model avoids a long-lived client secret, which is a significant improvement, but federation does not remove privilege. Scope the Azure application to only what the documented integration requires, record each granted permission with an owner and rationale, and review it like any other security service principal. Bootstrap privileges used during setup should not remain assigned to an administrator’s daily identity.

Decide where response authority lives

One queue tends to create an assumption that one team owns remediation. In multicloud estates, it often does not. The AWS security team may administer Security Hub while an Azure platform team owns policy, identity, and network changes. A finding can be centrally prioritized and still require a provider-native responder.

Define a RACI by finding family before routing the first alert. The central SOC can be accountable for triage and incident declaration; cloud platform teams can be responsible for configuration changes; application owners can be consulted on availability impact; governance can be informed of exceptions. For identity findings, Entra and IAM responders may need different playbooks even when the user journey looks similar.

Do not automate a single remediation command across providers simply because the findings share a category. “Remove public access” can mean a security group rule, a network security group, a service endpoint policy, a Function App access restriction, or an application-layer change. Normalize the outcome; keep the execution provider-aware.

Build one risk grammar

A useful cross-cloud priority score should answer five questions in the same order for every provider:

1. Is the resource reachable from an untrusted source?
2. What identity or workload could an attacker become from there?
3. What sensitive system or data can that identity reach next?
4. Is the exposure actively observed, merely configured, or inferred from incomplete data?
5. What is the blast radius if the path succeeds?

This grammar avoids false equivalence. Provider severity becomes one input, not the answer. The output should be an explainable priority with the path that justifies it: internet to function, function to managed identity, identity to vault, vault to production database. A high finding with no viable path can wait behind a medium finding that completes that chain.

Establish a coverage ledger

The phrase “Azure is connected” hides too much. Maintain a ledger by tenant, management group, subscription, resource family, region, and signal type. For each cell, record whether the asset is discovered, configuration is evaluated, vulnerability data is available, network exposure is analyzed, identity context is present, and activity telemetry is current.

Reconcile discovered counts against Azure Resource Graph rather than trusting either system alone. Investigate deltas above a set threshold. Track unsupported resource families openly; a unified view that quietly omits data services, Kubernetes configuration, or platform-specific controls can create more confidence than coverage.

The ledger should also distinguish preventive policy from detective assessment. Azure Policy may block a configuration while Security Hub reports another after deployment. Both matter, but they measure different moments in the control lifecycle.

Run a 45-day proof, not a console tour

AWS offers an independent 30-day free trial for Azure resources and prices them at the same rates as equivalent AWS resources. That is enough time to test signal quality, but only if baseline work starts before the clock does. Inventory the intended Azure scope, select representative subscriptions, and predefine success measures first.

During the proof, measure discovery completeness, finding latency, duplicate rate, percentage with a valid owner, analyst time to native evidence, true-positive yield, and remediation cycle time. Compare a cohort routed through the unified queue with the existing Azure-native workflow. A good outcome is not more findings. It is faster, more consistent resolution of the risks that matter, without losing native detail.

Include failure drills. Revoke a non-production permission, pause a diagnostic setting, and narrow connector scope. Confirm that the platform reports degradation and that an independent Azure alert catches the change. A security integration should prove it fails loudly before it is trusted silently.

What Security Hub should not become

It should not become a reason to dismantle provider-native expertise. Azure’s identity, policy, and networking semantics remain Azure’s. Nor should it become the only archive for evidence or the only monitor of its own access. Centralization is valuable when it creates a common decision and dangerous when it creates a common blind spot.

The strategic promise is real: one place to compare risks that used to live in separate organizational worlds. Realizing it requires more than connecting an Entra tenant. It requires a common risk grammar, a coverage ledger, independent connector monitoring, and a response model that knows when to centralize judgment and when to hand execution back to the cloud that owns the control.

Sources and reporting notes

• AWS announcement: Security Hub adds Microsoft Azure support, July 14, 2026.
• AWS prerequisites for the Azure integration, consulted for identity and permission requirements.
• AWS connector setup and health documentation, consulted for timing, standards, and failure behavior.

---

CloudDefender gives AWS teams the resource and identity relationships needed to turn normalized findings into prioritized attack paths, while preserving the cloud-native context responders need to act safely.