Every cloud team eventually has to decide whether the security services built into its provider are enough, or whether to pay for an independent layer on top. The question is rarely "native or third-party" in the abstract. It turns on how many clouds you run, how deep you need detection to go, who has to read the findings, where the security data is allowed to live and how much operating effort your team can absorb. This guide compares threat model, architecture, failure modes, controls, cost and decision criteria, with a worked scenario. It is written for cloud security leads, architects and buyers. Platforms are listed alphabetically throughout, and the order is never a ranking.
Key takeaways
- Native first is the sensible default for one cloud. Provider services see the control plane directly, need no extra credentials and are billed with the platform, so a single-cloud estate can usually reach a strong baseline with them alone.
- The case for a third-party layer grows with every additional cloud. Once findings sit in two or three consoles with different severity scales and schemas, a single normalised view and one policy language start to pay for themselves.
- Third-party tools add an identity you must secure. An external platform holds read (and often write) roles in every account it scans, which makes it one of the most privileged non-human identities in the estate.
- Data residency and retention differ by tool, not by category. Native and third-party services both copy configuration and log data into their own stores; check where each one keeps it and for how long before you sign.
- Most mature estates run a hybrid. Native services as the sensors and enforcement points, a normalised layer for correlation and reporting, and a clear owner for each finding type so nothing is triaged twice or not at all.
What each option is
Native controls are the security services the cloud provider builds and operates inside its own platform: posture assessment against benchmarks, threat detection from control-plane and network telemetry, vulnerability scanning of workloads, data classification and preventive guardrails such as organisation policies. The provider owns the sensor, the detection logic and the console. You own the configuration: which accounts and regions are enrolled, which standards are switched on and where findings go.
Third-party tools are platforms from independent vendors that connect to one or more clouds through APIs (and sometimes agents or snapshots), pull configuration and event data into their own environment, and present findings, attack paths and compliance views across providers. Typical categories are CSPM, CWPP, CIEM, cloud detection and response, and the combined CNAPP. The category overview is in the CNAPP Guide, and posture management on its own is covered in the Cloud Security Posture Management (CSPM) Guide. This page does not repeat those: it focuses on the build-or-add decision.
How the native services reach beyond their own cloud
Before assuming you need a third-party layer for multi-cloud coverage, check what your primary provider's service already connects to. Each provider documents its own approach; the summaries below are taken from the vendors' documentation as of November 2026.
- AWS Security Hub CSPM: collects security data across AWS accounts, AWS services and supported third-party products, normalises findings into the AWS Security Finding Format (ASFF) and checks controls against the AWS Foundational Security Best Practices standard plus CIS, PCI DSS and NIST standards. Cross-Region aggregation replicates findings, insights, control statuses and security scores from linked Regions into one home Region, and AWS states it adds no cost. Findings can be routed through Amazon EventBridge and custom actions to ticketing or automated remediation. See the AWS Security Hub Guide.
- Google Cloud Security Command Center: offered in Standard, Premium and Enterprise tiers. The Enterprise tier documents connectors for AWS and Azure that collect configuration metadata and resource data for posture assessment, attack path identification and compliance mapping, with log data such as CloudTrail connected separately. Google states that the Enterprise tier will shut down on 21 May 2027, with organisations moving to Premium on or after that date, so check the current tier documentation before designing around it. See the Security Command Center Guide.
- Microsoft Defender for Cloud: evaluates resources across Azure, AWS and Google Cloud. Its AWS connector onboards a single account or a management account (which auto-provisions member accounts), authenticates with federated trust and short-lived credentials, and offers Defender CSPM, Defender for Servers, Defender for SQL, Defender for open-source databases and Defender for Containers plans for AWS. Defender CSPM queries AWS resource APIs several times a day with read-only calls. See the Microsoft Defender for Cloud Guide.
Availability notes: AWS states that most Security Hub CSPM control findings depend on AWS Config recording, that the service processes findings only in Regions where it is enabled, and that full CIS AWS Foundations Benchmark coverage needs it enabled in all supported Regions. Google states that the AWS and Azure connectors belong to the Enterprise tier, which requires organisation-level activation. Microsoft states that each Defender plan may incur charges, that the AWS connector is not offered on national government clouds, and that an AWS account connected to Microsoft Sentinel cannot also be connected to Defender for Cloud.
A native service may already give you a cross-cloud posture view, expressed in that provider's own severity scale, policy language and console.
Side-by-side comparison
| Factor | Native controls | Third-party layer |
|---|---|---|
| Coverage across clouds | Deepest on the home cloud; reach into other clouds varies by provider and tier | Designed for consistent coverage across supported clouds; depth per cloud depends on the vendor's connectors |
| Data access | Control-plane telemetry inside the provider, often without extra credentials | API roles, and sometimes agents or snapshot scanning, granted in every account |
| Policy language | One per provider (for example AWS Config rules, Azure Policy, Google organisation policies) | One across clouds, usually with custom rule support |
| Finding format | Provider schema (ASFF on AWS, for example) | Vendor schema, sometimes mapped to an open schema such as OCSF |
| Cost model | Usage-based, per resource, check or plan, billed with the cloud | Licence per workload, resource or spend band, billed separately |
| Data location | Provider stores; residency options set by the provider | Vendor's tenancy; residency options set by the vendor contract |
| Lock-in | Tied to the provider; exit means rebuilding detection elsewhere | Tied to the vendor; exit means rebuilding rules and reporting, but cloud choice stays open |
| New identity risk | Provider service roles, managed by the provider | External cross-account roles with broad read, sometimes write |
Threat model for each option
Each approach changes what an attacker would target and what you would miss.
Native controls, what can go wrong:
- Coverage gaps by enrolment: services that are enabled per account and per region leave blind spots wherever a new account, region or subscription is created without them.
- Same-plane tampering: an identity with enough privilege in the account can often disable or reconfigure the native service it is being watched by. Delegated administration and policies that deny changes to security services counter this.
- Fragmented triage: findings in separate consoles are not correlated, so a path that crosses clouds looks like two unrelated low-severity events.
Third-party layer, what can go wrong:
- Privileged integration identity: the cross-account roles, service principals or service accounts that the tool uses are high-value targets. A compromised vendor tenant or leaked integration credential gives read access to configuration across every connected cloud, and write access if remediation is enabled. Securing that platform is its own discipline: see Securing the CNAPP and CSPM platform itself.
- Security data outside your boundary: configuration snapshots, asset inventories and sometimes disk snapshots are copied into the vendor's environment. That is a third-party risk and a data residency question, not only a technical one.
- Connector lag and silent failure: a broken connector or an unsupported new service produces no findings, which looks identical to a clean estate unless you monitor connector health.
Where identity fits
Whichever option you choose, the security tooling itself runs on non-human identities. Native services use provider-managed service roles. Third-party platforms need you to create cross-account IAM roles with external IDs on AWS, app registrations or managed identities on Azure, and service accounts or workload identity federation on Google Cloud. Treat those identities as tier-zero: least privilege (read-only unless remediation is a documented requirement), federation and short-lived tokens in place of long-lived keys, alerting on any change to their trust policies, and a named owner. Microsoft's own documentation for the Defender AWS connector, for example, describes federated trust and short-lived credentials and offers a least-privilege access option at onboarding. The Multi-Cloud Identity Guide and the Cloud PAM and CIEM Guide cover the identity design in depth.
Cost curve: how spend behaves as you grow
Comparing list prices is misleading because the two models scale differently.
- Native, usage-based: cost tracks resources, checks or enabled plans per account and region. For AWS, the current Security Hub pricing page lists CSPM within an Essentials plan billed per resource unit per month (EC2 instances, ECR images, Lambda functions and IAM users and roles), with a 30-day free trial per account and Region. Supporting services, such as AWS Config recording, are billed on top. Spend rises smoothly with the estate.
- Third-party, licence-based: cost usually tracks workloads or cloud spend bands and is negotiated annually. Entry cost is higher, but per-cloud cost does not multiply when you add a provider, because one licence covers every connected cloud the vendor supports.
- Hidden costs on both sides: SIEM ingestion, tuning time per console, duplicate triage and connector upkeep. In a hybrid model, write down which tool and team own each finding type, or the same issue is triaged twice.
A useful rule: model total cost of ownership over three years at today's size and at your expected size, including people. Single-cloud estates usually find native cheaper at every size. Multi-cloud estates often reach a crossover point where the cost of running two or three native stacks (tools plus people) exceeds one licence.
Depth: what each does well
| Capability | Native strength | Third-party strength |
|---|---|---|
| Posture against benchmarks | Provider benchmarks and CIS mappings maintained by the provider | One benchmark view across clouds; custom frameworks |
| Control-plane threat detection | Direct access to provider telemetry and provider threat intelligence | Cross-cloud correlation of events into one incident |
| Identity and entitlement analysis | Provider-specific analysers of its own policy language | Effective permissions compared across providers and identity providers |
| Attack path analysis | Within the provider's graph of its own resources | Paths that cross clouds, SaaS and code repositories |
| Prevention | Organisation policies and guardrails enforced by the platform itself | Mostly detective, plus shift-left checks in CI pipelines |
One asymmetry matters most: prevention is native. Service control policies, Azure Policy deny effects and Google organisation policy constraints are enforced by the platform at the API; a third-party tool can deploy them but not replace them. See the Cloud Landing Zone Security Guide.
Single pane, normalisation and SOC workflow
The "single pane of glass" argument is really about three things: one severity model, one schema and one place to assign ownership. Native services each normalise within their own world (AWS uses ASFF, for example). If your SOC already works from a SIEM, you can forward native findings there and normalise once, which gives much of the single-pane benefit without a new platform. The Open Cybersecurity Schema Framework (OCSF), accepted as a Linux Foundation project in November 2024, is a vendor-agnostic schema designed to give analysts a common language across tools; asking whether both your native exports and any third-party tool can map to it is a reasonable evaluation question.
A third-party layer earns its place when the readers are risk owners and auditors who need one report per business service. See the Cloud Detection Engineering Guide for routing and tuning.
Data residency and sovereignty
Both options copy your configuration and event data. Ask the same questions of each:
- Where is it stored? Microsoft documents, for example, that machine data collected by Defender for Cloud goes to a Log Analytics workspace and region you can specify (UK machines default to a United Kingdom workspace, most of Europe to Europe), and that Defender for Storage keeps artifacts in the region of the related resource. Third-party vendors set residency per tenant or contract; get it in writing.
- How long is it kept? Microsoft states that the Defender for Cloud cloud security graph keeps data for 14 days, with calculated data such as attack paths possibly kept for a further 14. Retention for each third-party platform is set by its contract and documentation.
- What leaves the boundary? Snapshot-based scanning may copy disk contents for analysis. Check whether scanning happens in your account or the vendor's.
- Which sovereign clouds are supported? Government and sovereign regions often have reduced feature sets on both sides; see the Data Sovereignty and Residency Guide.
Lock-in and exit
Both options create dependency. Native lock-in ties detection logic, dashboards and automation to one provider: moving clouds means rebuilding them. Third-party lock-in ties custom rules, exceptions, risk acceptances and historical trend data to one vendor: changing vendor means rebuilding those, but your cloud choice stays open. Reduce either kind by keeping detection rules and exceptions as code in your own repository, exporting findings continuously to a store you control, and writing exit provisions into contracts. NIST CSF 2.0 GV.SC-10 asks that supply chain risk plans cover activities after a partnership or service ends, which applies to security vendors as much as any other. See the Cloud Concentration Risk and Exit Strategy Guide.
Choosing: decision guidance
| Situation | Usual fit | Why |
|---|---|---|
| One cloud, small team | Native | Lowest cost and effort; deepest coverage of the platform you use |
| One cloud, large regulated estate | Native, plus SIEM normalisation | Native depth with central correlation; add a third-party layer only for specific gaps |
| Two or more clouds of similar weight | Third-party layer over native sensors | One policy language, severity model and report across providers |
| One primary cloud, small footprint elsewhere | Native, using the primary provider's cross-cloud connectors where they meet requirements | Avoids a new platform for a minor footprint; check tier and plan availability |
| Strict residency or sovereign cloud | Whichever option documents support for that region | Feature parity in sovereign regions varies on both sides |
| Non-specialist consumers of findings | Third-party layer or strong SIEM reporting | Business-service views matter more than provider depth |
Small vs large organisations: a small team gains most from turning on native services organisation-wide and routing high-severity findings to one queue. A large multi-cloud organisation usually needs a normalised layer, with native threat detection kept running underneath.
Worked scenario: primary cloud plus an acquisition
A company runs most workloads in one cloud with native posture and threat detection enabled organisation-wide. It acquires a business running on a second provider. The illustrative steps it takes:
- Enables the second provider's native posture and threat detection across the acquired organisation on day one.
- Checks whether its primary provider's service can connect the new cloud at the tier and plan it already pays for, and whether that meets its residency rules.
- Forwards both providers' findings into the existing SIEM and maps both schemas to one severity model, measuring cross-cloud triage time for three months.
- Models three-year cost for two native stacks plus people against one third-party licence plus people, at expected size after integration.
- Decides: if the second cloud stays small, stays native with SIEM correlation; if it grows to comparable weight, runs a proof of value for a third-party layer, with read-only integration roles and native threat detection kept on underneath.
How to implement: phased approach
- Baseline native: enable native posture and threat detection at organisation level in every account, subscription and project, in all regions, using delegated administration. Deny changes to these services with organisation policies.
- Centralise: aggregate findings per provider (for example AWS cross-Region aggregation to a home Region), then forward to the SIEM or ticketing system with an owner per finding type.
- Measure gaps: list what is not covered: other clouds, unsupported services, cross-cloud paths, reporting needs. Only these justify a third-party layer.
- Pilot a layer if needed: connect one non-production organisation read-only, compare findings with native output for four to six weeks, and measure duplicate and unique findings.
- Roll out in rings: production read-only first, remediation permissions only for named, tested actions. Document the ownership split between native and third-party findings.
- Rollback plan: keep native services enabled throughout, so removing the third-party integration roles returns you to a known baseline without a coverage gap.
Detection and measurement
- Enrolment coverage: percentage of accounts, subscriptions and projects, in all regions, with posture and threat detection enabled. Target 100 per cent, alerting on any new account without it.
- Connector health: hours since last successful scan per connected account for each tool; alert when it exceeds the scan interval.
- Duplicate finding rate: share of findings raised by more than one tool. High rates mean triage is wasted and ownership is unclear.
- Mean time to remediate critical misconfigurations, per cloud.
- Integration identity changes: any change to the trust policy or permissions of a security tool's role should raise an alert and appear in this metric as zero unapproved changes.
Common failure patterns
- Buying a layer before switching on native services: the new tool reports thousands of findings that native guardrails would have prevented.
- Turning native services off to save money once a layer is in place: this removes provider threat telemetry and prevention, and makes any connector outage a total blind spot.
- Over-privileged integration roles: granting write or administrator rights "for remediation later" turns the security tool into the most valuable credential in the estate.
- Region and account drift: native services enabled in the regions in use at launch, but not in new regions or accounts, which is exactly where attackers deploy resources.
- No ownership split: both tools raise the same finding and both teams assume the other is handling it.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02, PR.PS-01, DE.CM-09, DE.AE-03 | Inventory of cloud services, configuration management, monitoring of runtime environments, correlation from multiple sources |
| NIST CSF 2.0 | GV.SC-07, GV.SC-10 | Third-party tool vendors as suppliers, including exit |
| NIST SP 800-53 Rev 5 | CA-7, SI-4, CM-6, RA-5 | Continuous monitoring, system monitoring, configuration settings, vulnerability scanning |
| NIST SP 800-53 Rev 5 | SA-9, SR-2 | External system services and supply chain risk plans for the security vendor |
| CIS Controls v8.1 | Controls 4, 8 and 15 | Secure configuration, audit log management, service provider management |
| ISO/IEC 27001:2022 Annex A | 5.23, 8.9, 8.16 | Information security for use of cloud services, configuration management, monitoring activities |
| NCSC Cloud Security Principles | Principle 13 | Audit information and alerting for customers |
Practitioner checklist
- Native posture and threat detection are enabled organisation-wide, in every region, with changes to them denied by policy.
- You have checked what your primary provider's service can already connect in other clouds, at your tier and plan.
- A three-year cost model includes people, log ingestion and supporting services, not only licences.
- Any third-party integration identity is read-only by default, federated where possible, owned and alerted on.
- Data location, retention and snapshot handling are documented for every tool, native and third-party.
- An ownership matrix says which tool and team own each finding type.
- Connector health and enrolment coverage are monitored with alerts.
- Detection rules and exceptions are kept as code, and findings are exported to a store you control for exit.
Standards and references
- AWS: What is AWS Security Hub CSPM?
- AWS: Cross-Region aggregation in Security Hub CSPM
- Google Cloud: Security Command Center overview
- Google Cloud: Connect Security Command Center to AWS
- Microsoft Learn: Connect AWS accounts to Microsoft Defender for Cloud
- Microsoft Learn: Defender for Cloud data security
- NCSC: The cloud security principles
- OCSF: Open Cybersecurity Schema Framework
Related NHI Mgmt Group resources: Cloud Security Guide, CNAPP Buyer's Guide, Cloud Detection and Response Guide, CIS Cloud Foundations Benchmarks Guide, Cloud Security Architecture Review Template.