A hybrid and multicloud security-posture program needs a common inventory, a way to assess configuration risk, and a method for prioritizing the paths attackers can actually use. The current Microsoft SC-100 scope explicitly includes security posture management across Azure, on-premises, AWS, and GCP. Microsoft Defender for Cloud, Azure Arc, and Microsoft Security Exposure Management participate in that architecture at different layers.
Defender for Cloud provides cloud security posture management and workload protection. Azure Arc extends Azure management and selected security capabilities to machines and resources outside Azure. Security Exposure Management correlates assets, identities, vulnerabilities, cloud findings, and external exposure into a cross-workload graph that can reveal attack paths toward critical assets. The architecture works best when these tools are treated as connected data and control planes rather than as three overlapping dashboards.
Use Defender for Cloud as the cloud posture and workload-protection plane
Defender for Cloud assesses Azure resources and can connect AWS accounts and GCP projects for multicloud posture management. Treat connector onboarding as part of the security architecture: decide whether connections are established at organization, management-group, or account scope, who owns the source-cloud permissions, and how new accounts or projects are automatically brought under assessment. Defender CSPM adds deeper posture features such as attack-path analysis, cloud security explorer, data-aware risk, and other capabilities that help prioritize security issues beyond a flat recommendation list.
Workload-protection plans add threat detection and runtime protections for supported servers, containers, databases, APIs, storage, and other services. Coverage differs by workload and cloud, so a multicloud plan should use Microsoft’s current support matrix rather than assuming feature parity between Azure, AWS, and GCP. Document gaps that require native-cloud controls or another security product. Architects should separate posture management from workload protection conceptually because the licensing, dependencies, and operational teams can differ even though the findings appear in related experiences.
Azure Arc extends Azure management to non-Azure machines
On-premises servers and machines in other clouds can be connected as Azure Arc-enabled servers. Arc also creates an Azure resource identity for those machines, which makes inventory, policy, extensions, tagging, and centralized operations possible. Protect the Arc onboarding process itself because a compromised service principal or deployment credential can become a cross-environment management path. The Connected Machine agent lets Azure represent those systems as resources so services such as Defender for Servers, policy, update management, and inventory can apply beyond native Azure virtual machines.
Microsoft currently recommends Arc onboarding for non-Azure and on-premises machines when organizations want the full Defender for Servers feature set. In AWS and GCP, Defender for Cloud connectors can automate Arc onboarding for supported servers. Arc therefore acts as a management bridge, not as a replacement for the source cloud.
Multicloud connectors bring AWS and GCP context into the posture view
Defender for Cloud uses multicloud connectors to discover and assess supported AWS and GCP resources. CSPM features are largely agentless after connector onboarding, while workload protection may introduce sensors, extensions, or Arc dependencies. Separate those deployment models so teams know which findings require only API-level visibility and which rely on software running on the asset. Cloud security posture management is largely agentless after the connector is established, while some workload-protection capabilities require additional components such as Azure Arc, Defender for Endpoint, or platform-specific integrations.
Design the connector permissions deliberately. Read-only discovery for posture needs different rights from automated agent deployment or workload-protection configuration. Use least privilege and document which source-cloud roles the Microsoft connector can assume, because a posture platform should not become an unnecessary high-privilege bridge between clouds.
Security Exposure Management correlates risk across workloads
Microsoft Security Exposure Management uses an enterprise exposure graph to connect assets, identities, vulnerabilities, workload context, and external attack-surface signals. The graph becomes more valuable when critical assets and ownership are maintained, because blast-radius analysis can then distinguish a path into an ordinary development server from a path into identity, production data, or regulated systems. This allows risk analysis to span endpoints, cloud resources, identities, and hybrid systems instead of treating each platform as an independent list of weaknesses.
That cross-workload view is especially useful when one weakness is harmless in isolation but dangerous in combination. An internet-exposed service, overprivileged identity, vulnerable endpoint, and reachable critical asset may form one practical attack path even though each issue originates in a different product or team.
Attack paths help prioritize remediation by reachability and impact
Defender for Cloud has cloud attack-path analysis, while Security Exposure Management adds broader cross-workload attack paths in the Defender portal. Current Microsoft guidance focuses these paths on exploitable routes from external or compromised entry points toward critical assets rather than generating every theoretically possible graph path.
Use attack paths to identify choke points and shared weaknesses that reduce several risks at once. A choke point can be an identity, exposed service, weak network path, or vulnerable asset that participates in many paths. Prioritizing those nodes helps security teams reduce systemic risk instead of spending equal effort on every recommendation with the same severity label. Removing one overprivileged identity, closing one exposed management interface, or protecting one high-value connector can break multiple attack paths and produce more risk reduction than fixing many isolated low-impact findings.
Critical-asset definition changes the value of exposure analytics
Attack-path and blast-radius analysis becomes more useful when the organization identifies which assets, identities, data stores, and business services are actually critical. A platform cannot prioritize toward crown jewels that have never been classified.
Security architecture should therefore connect technical inventory to business context. Tag critical systems, assign owners, maintain data sensitivity and service importance, and review those classifications as applications evolve. Exposure analytics without asset context can still find vulnerabilities, but it cannot reliably rank business consequence.
Posture data quality depends on complete onboarding
Exposure views are only as complete as their data sources. Missing cloud accounts, unprotected subscriptions, servers without Arc or endpoint signals, unsupported connectors, or unlicensed workloads can create blind spots. Microsoft explicitly notes that attack paths may be incomplete when relevant data is unavailable.
Track coverage as an architecture metric: which Azure subscriptions, AWS accounts, GCP projects, on-premises machines, endpoints, identities, and external assets feed the exposure graph? Include stale connectors, failed agents, missing critical-asset classification, and licensing gaps in the coverage report. Posture data should carry a confidence level based on how complete the source estate is. A posture program should report coverage gaps alongside security findings so leaders do not confuse partial visibility with low risk.
Unify posture management without erasing cloud-native ownership
Central posture does not mean every security control should be managed from one portal. Cloud-native services remain the authoritative place for many IAM, network, logging, and workload settings. Use Defender and Exposure Management to identify and prioritize the problem, then remediate through infrastructure as code, native policy, workload configuration, or the owning engineering pipeline. AWS, GCP, Azure, and on-premises environments retain their own native identity, network, logging, and service controls. Defender and Exposure Management should help prioritize and correlate, while remediation often occurs in the native platform or workload pipeline.
Keep source-system ownership explicit. A Defender recommendation should route to the team that owns the Kubernetes configuration, IAM policy, network rule, or virtual machine image. Centralized visibility is useful only when it leads to accountable changes in the systems where risk originates.
Build posture management as a continuous operating loop
The SC-100 architecture skill is the operating loop: discover assets, assess posture, identify attack paths, prioritize critical exposures, remediate at the correct control plane, and verify that the path is broken.
Use Defender for Cloud for cloud posture and workload protection, Azure Arc to extend management to non-Azure machines where appropriate, and Security Exposure Management for cross-workload exposure prioritization. Add verification after remediation: the recommendation should clear, the attack path should break, and the asset should remain covered by monitoring. Without that feedback loop, posture management becomes a reporting exercise rather than a risk-reduction system. The result should be fewer unowned findings and faster remediation of the paths that can actually reach critical business assets.
Operationally, the posture program should maintain one coverage dashboard that shows connected environments, critical-asset tagging, sensor or agent health where required, connector health, attack-path volume, and remediation aging. Review the largest blast-radius nodes regularly with cloud, identity, endpoint, and application owners. This keeps Exposure Management from becoming a security-team-only graph and turns it into a shared prioritization process for the engineering teams that can actually remove the risk.
Coverage reviews should also distinguish posture visibility from workload protection. A cloud account can be fully inventoried for CSPM while some servers, containers, databases, or APIs lack the sensors or plan required for runtime detection. Record those differences explicitly in the architecture. Otherwise leadership can see one connected account and assume every workload inside it receives the same protection depth.
Posture programs need remediation service levels that reflect attackability and business impact. An internet-exposed identity path to a critical subscription deserves a different response time from an isolated recommendation on a low-value lab resource. Use attack paths, critical-asset classification, exploitability, privilege, and external exposure together when prioritizing work. Then measure whether the remediation actually removed the path instead of counting the ticket as complete when a configuration change was submitted.
Maintain one coverage view that shows connected Azure subscriptions, AWS accounts, GCP projects, Arc-enabled machines, required Defender plans, critical-asset tagging, connector health, and any workloads intentionally outside coverage. Review those gaps with cloud, identity, endpoint, and application owners. This keeps centralized posture management honest: leadership can see the difference between a low number of findings and incomplete security visibility.