AWS Security Hub Extended: The End of the Platform vs Best-of-Breed Debate

 Enterprise security buying has for years been framed as a forced choice: consolidate to reduce complexity or live with complexity in exchange for depth. The recent launch of AWS Security Hub Extended (SHX) changes that framing and does so across three dimensions simultaneously: the buying model, the operational model, and the commercial model. 

By curating a specific cohort of ISV partners under a shared integration framework, AWS has created a procurement path that gives enterprises best-of-breed depth with platform-level simplicity. Giving that cohort a common integration layer, a common commercial motion, and a common customer base also creates conditions for genuine ISV-to-ISV collaboration that the security industry has historically struggled to produce. 

What AWS Security Hub Extended Actually Is: Foundation First, Best-of-Breed on Top 

At re:Invent 2025, AWS reimagined Security Hub from the ground up. The new platform unifies native AWS security services: Amazon GuardDuty for threat detection, Amazon Inspector for vulnerability management, Amazon Macie for data security, and AWS Security Hub CSPM for cloud posture management, all into a single continuously analyzing experience. 

For security teams managing high alert volume, findings from these services now correlate automatically, are prioritized by combined risk context, and surface in a single operational interface. That unified experience is the Security Hub Essentials offering, which remains the foundation and a prerequisite for what comes next. 

Security Hub Extended builds on that Essentials foundation by curating the best category specialists across endpoint, identity, network, browser, AI security, email, and security operations into the same unified experience. AWS native services combined with the best technology partners in each domain produce stronger enterprise security outcomes than any single-vendor stack can, and the SHX program is AWS acting on that directly. 

AWS native services + best-in-class ISV partners = stronger enterprise security outcomes than any single-vendor stack. 

 All findings are normalized to the Open Cybersecurity Schema Framework (OCSF) schema automatically, across both AWS-native and ISV sources. 

The Stack That Is Now Possible 

The visual below maps all 14 SHX ISV partners and the four AWS native services across their security domain, with the specific customer outcome each delivers.  

Two examples show how the better-together story works in practice, each using published integrations: 

Britive and Island: Britive enforces zero standing privileges across human identities, service accounts, and AI agents, generating OCSF-normalized findings in Security Hub Extended at every access event carrying identity context, the specific resource accessed, the time window, and the revocation event. Island sends browser-layer security events into Security Hub Extended covering session behavior, data exfiltration attempts, and access to unapproved applications. When a user in an Island-monitored session begins accessing sensitive resources outside their normal pattern, that browser-layer signal correlates in Security Hub Extended with Britive privilege data for the same user. If the user holds elevated cloud privileges through Britive at that moment, the combined risk picture is materially higher confidence than either product surfaces independently. A response can then reduce the privilege scope through Britive while Island enforces tighter session controls, all driven by the correlated finding rather than two separate alert queues requiring manual analyst work.  

Britive, CrowdStrike, and Splunk: CrowdStrike contributes behavioral detection and identity threat signals from the endpoint layer into Security Hub Extended. Britive contributes identity access events and privilege context for the same users and workloads. Security Hub Extended correlates those signals across both sources in OCSF, and when a compromised credential detected at the endpoint correlates with an anomalous Britive access request from the same user, the combined finding carries materially higher confidence than either product generates alone. Security Hub Extended then feeds those correlated findings into Splunk Enterprise Security in near real time, where analysts work from a single prioritized investigation surface spanning identity, endpoint, and cloud rather than three separate alert queues. At the same time, Britive can automatically revoke the privilege grant associated with that identity, reducing the blast radius before an analyst has even opened the alert. The manual correlation work is done before the finding reaches the analyst, and the most time-sensitive enforcement action does not wait for one. 

 Across the full cohort, the same principle applies at every security domain. Each ISV sends findings into Security Hub Extended in OCSF, each contributes to the correlated risk picture. The procurement and operational model connecting all of them is what SHX provides. 

What This Changes Commercially 

The commercial case for this stack is as important as the operational one. 

PAY-AS-YOU-GO 

Pre-negotiated, pay-as-you-go pricing with no long-term commitments required. No upfront investment. Consume what you need, when you need it. This is a meaningful shift from traditional security procurement. 

SINGLE BILL 

All AWS-native services and Extended plan ISV solutions appear on one monthly bill. Consumption-based metering is automated. Finance teams see one line item rather than multiple separate renewals. 

PRIVATE PRICING 

For organizations with existing AWS Enterprise Discount Programs or private pricing agreements, solutions transacted through Security Hub Extended count toward AWS spend thresholds, contributing to the same commercial lever that drives infrastructure discounting. 

UNIFIED SUPPORT 

AWS Enterprise Support customers receive unified Level 1 support across the entire extended plan. Cross-vendor blame-shifting is structurally addressed at the support layer.  

Pay-as-you-go. No commitment. AWS as seller of record. The security stack that used to require separate procurement cycles now requires one procurement cycle.  

SHX as the Catalyst Element 

Each ISV in this program does something well in isolation: CrowdStrike detects endpoint threats, Britive enforces zero standing privilege, Splunk correlates logs, Noma monitors AI pipelines. Without a shared data layer, a shared commercial motion, and a shared operational surface, those remain parallel capabilities running in silos. SHX provides all three, which is what turns a collection of strong individual products into a coordinated security program. 

SHX normalizes findings across all partners into OCSF, creates a single operational view, and gives enterprises a procurement path that treats the full stack as a single AWS-native purchase. The pay-as-you-go, no-commitment model lets organizations adopt incrementally, starting with the categories where they want to advance their security posture first, without signing up for a multi-year bundle that locks in modules they may not fully use. 

That last point matters. Most enterprise security platform deals require 3-5 year commitments across a broad set of modules. SHX lets customers compose precisely what they need and pay for exactly what they consume, which is a structurally different commercial posture. 

SHX provides the shared data layer, shared commercial motion, and shared operational surface that turns strong individual ISV products into a coordinated security program. 

A Third Path on Platformization 

The security industry has debated platform consolidation versus best-of-breed for years. That debate has been shaped by vendor marketing and analyst positioning more than by what was operationally achievable. 

Platform plays from Microsoft, Palo Alto Networks, and others deliver real value. Consolidated billing, unified support, tighter native integrations, and simplified vendor management are legitimate operational benefits. The trade-off is capability depth: no single vendor leads every security category. 

Best-of-breed stacks deliver category-leading depth and the ability to select the right solution for each domain, but at the cost of procurement complexity, integration burden, and support fragmentation. 

Security Hub Extended is a third path: platformized procurement with best-of-breed depth. 

AWS has done the curation, negotiated the commercial terms, built the integration layer, and unified the operational experience. The underlying solutions are category specialists, not a platform vendor's secondary products. Customers get both. 

Deep customization and ISV-specific capabilities may still require direct vendor engagement in some cases. But for the core use case of building a comprehensive, modern security program on top of an AWS native foundation, SHX gives enterprises platform simplicity and best-of-breed depth together, which is a combination that was not commercially or operationally achievable before this program existed. 

Platform simplicity and best-of-breed depth together, in a combination that was not commercially achievable before this program. 

Framework Coverage 

The native AWS layer provides direct control coverage against CIS AWS Foundations Benchmark, NIST CSF, PCI-DSS, and SOC 2. Security Hub Essentials surfaces findings tagged to these frameworks natively. 

For organizations building toward AI security requirements, including NIST AI Risk Management Framework, CSA AI Safety guidance, and OWASP Top 10 for LLM Applications, Noma and 7AI provide coverage that is increasingly referenced in emerging compliance and audit frameworks. Britive's zero standing privilege model and JIT access enforcement for agentic AI workloads maps directly to the least-privilege and identity assurance controls these frameworks emphasize for AI infrastructure. 

The OCSF normalization across all findings means organizations have structured, consistent evidence across the full control taxonomy, which simplifies both internal audit and external compliance reporting.  

Multi-Cloud Normalization and the Unified Security Fabric 

Multi-cloud is the current operating reality for most enterprises. AWS, Azure, and GCP deployments coexist within the same organization, often within the same business unit. The security challenge this creates for enterprise is both technical and operational. Different identity planes, different network controls, different posture frameworks, different logging formats, and different procurement relationships, all requiring separate tooling and separate teams to manage. 

AWS is directly addressing this with SHX, and has signaled clear intent to extend its native security services to multi-cloud environments 

The OCSF normalization layer within Security Hub Extended is inherently multi-cloud: it provides a common schema for security findings regardless of which cloud, which workload, or which ISV generated them. Several ISV partners in the SHX cohort already operate natively across AWS, Azure, and GCP. Britive manages zero standing privileges across all three. CrowdStrike protects workloads regardless of where they run. Zscaler secures how users and devices connect to cloud workloads across any environment, covering the user-to-cloud access enforcement layer. Splunk ingests and correlates from every source. The layer that remains an active area of development for multi-cloud architectures is network security enforcement within and between cloud environments, specifically workload-to-workload traffic across VPCs and cloud boundaries, where unified policy and visibility at the network layer becomes critical as workload sprawl grows. 

The practical outcome for an enterprise running SHX is a unified security operations experience that spans their full cloud footprint, not just their AWS estate. Findings from Azure-hosted workloads protected by CrowdStrike and GCP data environments monitored by Cyera normalize into the same Security Hub view alongside GuardDuty and Inspector findings from AWS. Security teams work from one operational surface instead of three. 

SHX delivers what enterprises are building toward: a unified security trust fabric that follows workloads and identities wherever they run. AWS extending native security capabilities in this direction, and curating ISV partners who already operate multi-cloud, reflects where enterprise infrastructure actually is.

Multi-cloud is where enterprise infrastructure lives. SHX and its curated ISV partners normalize security operations across that reality into a single view. 

Auto-Protect, Not Just Detect 

The security industry spent years optimizing for visibility: aggregate more signals, normalize more data, surface better alerts. That was the right problem to solve when threats moved at human speed and incident response could be human-led. That assumption no longer holds. 

AI agents operating across enterprise infrastructure, non-human identities executing workloads at scale, and automated pipelines touching sensitive systems and data mean that threats now propagate faster than any SOC team can triage and respond to manually. A compromised service account or a misconfigured AI agent with excess privilege can move laterally across a cloud environment in seconds. Waiting for a human to review an alert and open a ticket is not a viable response model at that speed. 

CISOs are increasingly asking a different question: not just where are the threats, but how do we block them automatically at the enforcement layer before they become incidents. The enforcement surfaces that matter now are identity, endpoint, network, and agent tool invocation, and the requirement is automated response at each layer, not just detection. 

SHX is positioned precisely at this inflection point. The intelligence gathered across 14 curated ISV partners and AWS native services, correlated and risk-scored within Security Hub Extended, creates the conditions for automated enforcement at each layer. An identity anomaly triggers a privilege revocation. A compromised endpoint triggers isolation. A confirmed credential compromise triggers network access cutoff. The enforcement surfaces that still need fuller coverage, particularly workload-to-workload traffic inside and between clouds, represent the next frontier for this architecture. The direction of travel is clear: from detection to enforcement, automatically. 

The shift CISOs are navigating right now is from detect and respond to detect and enforce automatically. SHX is built for the second posture. 

The Continuous Enforcement Loop 

Coverage of Security Hub Extended tends to focus on the ingestion side: alerts come in, get normalized, get prioritized. What gets less attention is the other half of what SHX does, which is feed assessed risk and correlated actions back out to ISVs for enforcement. 

1. Ingest and Assess 

All 14 ISV partners and AWS native services stream findings into Security Hub Extended continuously in OCSF schema. Threats, vulnerabilities, identity risks, AI pipeline signals, posture gaps, network exposures. Everything lands in one place, normalized. 

2. Correlate and Prioritize 

Security Hub Extended cross-correlates signals across all vendors. Risk scoring surfaces what matters. The goal is to identify the 3% of alerts that need immediate action from the 97% that is noise. Cross-domain correlation is where this gets genuinely powerful: a Proofpoint-detected phishing attempt against a specific user, combined with an anomalous Britive access request from that same user, produces a risk signal that neither product could generate independently. 

3. Enforce and Remediate 

This is where correlated risk assessments could drive enforcement actions back to ISVs via mechanisms like the Shared Signals Framework and direct integrations. In this model, Britive revokes access or removes a privilege grant. CrowdStrike isolates an endpoint. Okta suspends a session. Splunk fires a response playbook. The assessment drives action across the stack rather than producing only an alert. This is the direction the architecture is heading. 

SHX launched with signal ingestion, normalization, and consolidated procurement as the foundation. The direction it is heading is more significant. In my view, the bidirectional enforcement loop is the natural next step for this architecture. Whether it materializes through direct product integrations, AWS-native mechanisms, or a combination of both, the structural conditions for it to scale are already in place. For enterprises evaluating SHX today, that trajectory is already underway. 

In my view, the direction SHX is heading is a control plane that receives signals from 14 ISVs and fires enforcement actions back to them in a continuous loop. The architecture for it is already in place. 

Security Close to Where It Matters: Workload Gravity and AI Infrastructure 

For enterprises running AI workloads, one of the most practical but underappreciated benefits of the SHX architecture is what happens when security tools sit inside the infrastructure rather than alongside it. The principle is straightforward: security tools that are close to the data, the compute, and the inference layer produce richer signals, enforce faster, and require less manual instrumentation than tools that observe the same environment from the outside. 

AWS native security services deliver this natively. GuardDuty Runtime Monitoring runs inside the container and Lambda execution environment. CloudTrail captures every Bedrock API call at the moment it occurs. Security Hub Extended correlates those signals at the infrastructure layer without requiring customers to build the integration themselves. The practical benefit for a security team is a more complete, lower-latency security picture with less operational overhead, because the detection layer is woven into the infrastructure rather than bolted on top of it. 

SHX extends that benefit by curating ISVs that operate within or tightly adjacent to the AWS infrastructure layer. For AI workloads specifically, the most urgent enforcement question this raises is privileged access control for AI agents. When an AI agent running on Bedrock or SageMaker needs access to a database, an S3 bucket, or an external API, the customer requirement goes beyond logging: the access needs to be time-bound, workflow-governed, and automatically revoked the moment the task completes, without a human in the loop, at the speed the agent operates. 

Britive addresses this by operating natively inside the AWS IAM plane rather than observing it from outside. Privileged access enforcement for AI agents is applied at the moment of the request and revoked automatically when the session ends, within the same identity fabric the AWS workload already trusts. The customer benefit is a defensible, auditable ZSP posture for AI agents that does not require additional integration work or manual revocation workflows. SHX combined with Britive and Noma gives enterprises that posture across AI agent privileged access enforcement and AI pipeline security without assembling it from disconnected vendor relationships. 

The customer benefit of security tools that sit close to the infrastructure is a more complete, lower-latency security posture with less integration overhead. SHX is how AWS makes that available across both native services and a curated ISV stack. 

What This Signals About AWS's Ecosystem Strategy 

Building the OCSF integration layer, negotiating commercial terms with ISV partners, building the unified support model, and integrating the procurement flow into the SHX console required AWS to operate as a platform integrator for the enterprise security ecosystem. Customers buying security are not buying individual services but a full security program, with all the commercial, operational, and compliance complexity that entails, and SHX is AWS building for that reality. 

For ISVs in this program, the AWS curation itself carries commercial weight with enterprise customers and field teams, in a way that self-reported competency designations generally do not. 

The Cohort Effect: When ISVs Collaborate, Not Just Coexist 

ISVs in adjacent security categories have historically operated in parallel: sharing customers, showing up on the same shortlists, occasionally building point integrations to say they interoperate. The incentive structure to deeply collaborate has been weak because each ISV optimizes for its own product surface, its own renewal, its own expansion motion. 

Security Hub Extended changes that by giving a curated cohort of ISVs a common integration layer (OCSF-normalized findings in Security Hub Extended), a common commercial motion (AWS as seller of record), and a common customer base, making genuine partner collaboration structurally possible rather than aspirationally distant. To illustrate what that could look like in practice, consider these examples of integrations that the shared data layer makes tractable, even where they do not yet exist as formal joint offerings:  

Identity meets AI security: Take Britive and Noma as an example. Both operate on adjacent surfaces, Britive governing who and what can access cloud resources, Noma governing the security of the AI pipelines those identities interact with. A joint integration between the two, enabled by the shared OCSF data layer in Security Hub Extended, could enforce identity-aware access controls at the boundary of AI model inference, tying ZSP to AI pipeline security in a way neither product addresses independently today. 

Browser security meets identity: Island controls what a user can do inside a browser session. Britive controls what privileges that user carries at the time of access. Because both products now share a common data layer in Security Hub Extended, a coordinated workflow between session-level browser enforcement and just-in-time privilege grants becomes architecturally tractable, potentially enforcing the full access lifecycle from authentication through session behavior to automatic revocation across SaaS and cloud environments. 

AI-powered SOC meets extended detection: 7AI's generative AI capabilities applied to CrowdStrike's endpoint telemetry, with findings already normalized in OCSF within Security Hub Extended, could create an investigation surface materially richer than what any single product provides. The shared normalization layer reduces the integration work that would otherwise make this kind of cross-product enrichment prohibitively complex. 

Email threat context meets identity response: Imagine Proofpoint identifying a targeted phishing attempt against a specific user, with that finding surfaced in Security Hub Extended alongside Britive privilege data for that same user. A workflow could then automatically reduce the privilege footprint of that user's accounts while investigation proceeds, limiting blast radius before a credential compromise is weaponized. That kind of cross-domain response becomes architecturally possible when two ISVs share a normalized data layer, even if the specific automated trigger requires direct integration work between the two products. 

These are examples of integration patterns that become architecturally tractable when the underlying data normalization, procurement alignment, and shared customer base are already in place. Whether any specific joint integration gets built depends on each ISV's roadmap and commercial decisions, but the structural conditions for them to exist have never been better. 

Security Hub Extended functions as a collaboration framework, not just a distribution channel. The partners who invest in joint solution engineering with cohort peers, building reference architectures and integrated workflows across the Extended plan ecosystem, will deliver differentiated outcomes that neither single-vendor platforms nor fragmented best-of-breed stacks can match.  

The partners who invest in joint engineering across the SHX cohort will build outcomes that neither a single-vendor platform nor a fragmented stack can replicate. 

Closing Thoughts

The consolidate-versus-best-of-breed framing has run its course as the defining question in enterprise security buying. The more useful question for any CISO or security architect right now is how to build the security depth your organization needs, at a pace and cost model that your business can absorb, across a cloud footprint that is already multi-cloud and getting more complex. 

Security Hub Extended addresses all three simultaneously: curated best-of-breed depth, pay-as-you-go consumption with no long-term commitment, and a normalization layer that works across cloud environments. The architecture is live, the ISV ecosystem is integrated, and the enforcement loop infrastructure is being put in place. 

Credit where it is due. Programs like SHX do not happen by accident. It requires deep understanding of how security is bought and operated, where the existing model creates unnecessary friction for customers, and the organizational will to build something structurally different in response. AWS did that with SHX. 

For anyone in the AWS security field, partner, or customer organization who has not looked closely at this program yet, now is the time.