Misreading cloud shared responsibility creates customer-side exposure at the control-plane boundary.
NSA and CISA's joint Top Ten Cloud Security Mitigation Strategies opens with upholding the shared responsibility model and centers its customer-side guidance on identity and access management, secure logging, and configuration — the areas where customer authority, left unexercised, becomes exposure. These failures occur where customers retain authority over configuration state but fail to exercise it.
The shared responsibility model allocates control-plane authority, not vendor responsibility. Understanding which party can take which API actions — and which party is accountable for the resulting configuration state — determines where security controls must be implemented.
What The Shared Responsibility Model Actually Allocates
The shared responsibility model divides control-plane authority between provider and customer along service boundaries. The provider controls infrastructure plane operations: hypervisor patching, hardware lifecycle, physical network fabric, and service availability operations. The customer controls configuration state within their accounts, subscriptions, or projects: IAM policy authoring, logging enablement, network controls inside account boundaries, encryption key management, and data protection.
This authority allocation shifts with service models. In IaaS, the customer manages operating system patching, application configuration, and runtime security for EC2 instances or Azure VMs. In PaaS, the provider patches the managed service runtime while the customer configures access policies, data protection, and application logic. In SaaS, the provider operates the application while the customer manages user provisioning, data classification, and access governance.
The Cloud Security Alliance Cloud Controls Matrix explicitly maps shared responsibility for each control across IaaS, PaaS, and SaaS service models, identifying that the customer-controlled scope expands as the service model moves toward IaaS and contracts as it moves toward SaaS. The boundary moves per control, not as a single line.
The allocation determines accountability. If the customer has API authority over a configuration, the customer is accountable for its security state — regardless of how complex the service architecture becomes.
Provider Actions through the Control Plane
Provider authority operates below the account boundary. Cloud providers can patch hypervisors, replace failed hardware, restore data center power, and route around network fabric failures. Providers cannot set customer IAM policies, enable customer audit logging, configure customer network security groups, or manage customer encryption keys.
The provider's control-plane authority ends at the account, subscription, or project boundary. AWS cannot modify your IAM role trust policies. Azure cannot enable your Activity Log retention. GCP cannot configure your VPC firewall rules. The provider's infrastructure operations occur in a different authority scope than customer configuration management.
This separation has security implications. In normal operation, provider infrastructure events — including isolation or availability failures — do not carry authority to modify customer-controlled IAM policies or logging configuration; that authority stays with the customer. The model describes where authority sits during normal operation; it does not by itself speak to what a compromise of the provider's own infrastructure could reach. Provider security certifications cover provider-controlled infrastructure operations, not customer-controlled configuration state.
The provider can take emergency actions that affect customer resources — stopping instances during abuse investigations or suspending accounts for policy violations — but these operate through documented service terms, not through modification of customer-controlled security configuration.
Customer Actions at the Boundary
Customer authority operates within account boundaries through API-driven configuration. The customer controls IAM policy authoring and least-privilege enforcement. This includes creating roles, policies, and permission boundaries; configuring MFA requirements; and managing identity federation with external IdPs.
Customers control logging configuration across all cloud services: In AWS, this means enabling CloudTrail for API logging, GuardDuty for threat detection, and Config for resource change tracking. In Azure, this means configuring Activity Logs, Microsoft Defender for Cloud, and Azure Monitor. In GCP, this means enabling Cloud Audit Logs, Security Command Center, and Cloud Monitoring. The provider operates the logging infrastructure; the customer controls whether logging is enabled and where logs are retained.
Customers control network configuration within their account scope: This includes VPC or virtual network creation, subnet allocation, security group rules, network ACLs, and private endpoint configuration. The provider operates the underlying network fabric; the customer controls how their resources connect through it.
Customers control encryption key management for customer-managed keys:The provider can offer key management services, but customers decide which keys to use, when to rotate them, and which resources they protect. Provider-managed keys exist for convenience, but customer-managed keys provide customer control over the encryption boundary.
Where the Boundary Creates Security Implications
The authority boundary creates specific exposure surfaces where misreadings produce gaps. First, the provider patches hypervisors but customer-managed operating systems remain customer responsibility in IaaS. AWS patches the EC2 hypervisor; you patch the Ubuntu instance running on it. This creates a boundary where provider infrastructure security does not extend to customer-managed OS security.
Second, the provider operates SaaS applications but customer data governance remains customer responsibility. Microsoft operates Office 365; you control which users access which documents and how long deleted items are retained. The provider's application security does not extend to customer access policies or data protection requirements.
Third, the provider operates managed database services but customer schema and authorization remain customer responsibility. AWS operates RDS infrastructure; you control database user permissions, schema design, and query authorization. Provider database infrastructure security does not extend to customer data access patterns.
Fourth, the provider runs IdP federation services but customer policy enforcement remains customer responsibility. Azure operates Microsoft Entra ID; you configure conditional access rules, MFA enforcement, and application consent policies. Provider identity infrastructure does not extend to customer access policy decisions.
Each boundary creates a handoff where one party's authority ends and the other's begins. Security gaps occur when customers assume provider authority extends beyond the actual boundary.
Common Misreadings of Shared Responsibility
Reading shared responsibility as "the provider handles security" creates customer-side exposure. The provider handles infrastructure security below the account boundary; the customer handles configuration security within the account boundary. Provider security operations do not extend to customer IAM policies, logging configuration, or network controls.
Reading shared responsibility as a single line across all services creates boundary confusion. The boundary varies per service and per control. S3 bucket policies are customer-controlled; S3 infrastructure operations are provider-controlled. Lambda function code is customer-controlled; Lambda runtime patching is provider-controlled. The line moves with each service decision.
Reading shared responsibility as fixed creates operational drift. Service updates can shift boundary allocation as managed services evolve from PaaS toward SaaS functionality. What was customer-managed in one service version may become provider-managed in the next, requiring configuration review when services change.
Assuming provider certifications cover customer-side controls creates compliance gaps. [Provider SOC 2 or ISO 27001 certifications cover provider-controlled infrastructure operations, not customer-controlled configuration state]. Your IAM policy design, logging enablement, and network configuration require separate evidence generation for audit purposes.
What to Verify in Your Environment
Verify IAM policy authorship authority across all accounts, subscriptions, or projects. Document which teams can create roles, modify policies, and grant permissions. Confirm that least-privilege enforcement operates through customer-controlled policy, not provider default restrictions. Test that emergency access procedures operate within customer-controlled IAM boundaries.
Verify logging enablement evidence across all cloud services in use. Confirm API logging (CloudTrail, Activity Logs, Cloud Audit Logs) captures control-plane actions. Verify that security monitoring (GuardDuty, Defender for Cloud, Security Command Center) operates on customer-enabled data streams. Document log retention policies under customer control, not provider defaults.
Verify encryption key ownership and rotation control for sensitive workloads. Identify which resources use customer-managed keys versus provider-managed keys. Confirm key rotation operates under customer policy, not provider convenience. Test that key revocation affects resource access as expected.
Verify network control configuration operates within customer authority scope. Document which security groups, network ACLs, and firewall rules protect critical resources. Confirm that network segmentation operates through customer-controlled configuration. Test that private connectivity operates through customer-managed endpoints.
Create a per-service shared responsibility matrix for newly adopted cloud services. Map customer-controlled versus provider-controlled aspects for each service before deployment. Update the matrix when service capabilities change or when moving between service tiers. Use the matrix to identify where customer security controls must be implemented.
The verification establishes that customer-side security operates through customer-controlled configuration, not through provider infrastructure security that extends beyond its actual authority boundary.
Sources