The Shared Responsibility Model Has a Fourth Party: Your AWS Reseller

Every cloud security conversation eventually quotes the shared responsibility model. AWS secures the cloud: the data centers, the hardware, the hypervisor, the managed service internals. You secure what you put in the cloud: your identities, your configurations, your data, your network rules. It is a clean two-party diagram, and it is correct as far as it goes.

It stops being sufficient the moment a third company sits between you and AWS. A large share of startups and mid-sized companies buy AWS through a reseller, a distributor, or a managed service provider. The reasons are sensible: credits, consolidated invoicing, local-currency billing, a support relationship, sometimes a discount. The side effect is rarely discussed. Your accounts may live inside an AWS Organization that someone else owns. And in AWS, the organization is where a surprising amount of security control lives.

This post explains the fourth party in practical terms. You will learn which controls belong to whoever owns the organization, how to find out in about ten minutes whether that is you, what to put in a contract or an email to your reseller, how to take control back when you need it, and what you can still do from inside a member account while you wait. It is written for security leaders, platform engineers, and anyone who has been told “we are on AWS, so we are covered” and wants to know what that actually means.

The two-party model, and the sentence it leaves out

The AWS version of shared responsibility is worth stating precisely, because the fourth-party problem is a gap in how people apply it, not in the model itself. If you want the fundamentals first, our explainer on the shared responsibility model covers them.

• AWS is responsible for security of the cloud. Physical facilities, host infrastructure, the software that runs managed services.
• You are responsible for security in the cloud. IAM configuration, network exposure, data protection, logging, patching of what you run, and the way you use each service.

Notice what the model assumes: that “you” is one coherent party that can change any configuration it needs to change. That assumption is exactly what breaks when your accounts are members of an organization owned by a reseller. In that setup, some of the things AWS puts on your side of the line are, in practice, not changeable by you at all, because they are organization-level settings that only the management account can alter.

So the real question is not “what is my responsibility?” It is “which of my responsibilities can I actually exercise?”

Why the organization matters more than the account

An AWS account is a boundary for resources and billing. An AWS Organization is a layer above it. It has one management account and any number of member accounts. The management account can do things no member account can:

• Service control policies (SCPs). Guardrails that cap what any identity in a member account can do, including its administrators. An SCP that denies an action beats an IAM policy that allows it. A member-account administrator cannot see through, edit, or remove an SCP applied from above.
• Organization-wide services. IAM Identity Center (the AWS-native way to do single sign-on across accounts), organization CloudTrail trails, AWS Config aggregators, GuardDuty and Security Hub administration, and Backup policies are enabled and delegated from the management account.
• Consolidated billing and commercial terms. Who pays, which support plan applies, how discounts and credits are shared.
• Account lifecycle. Inviting accounts in, removing them, closing them.
• Sometimes, a role into your accounts. Resellers and managed service providers often deploy a cross-account role so they can provide support, cost reporting, or security monitoring. That role is part of your attack surface.

None of this is sinister. Most resellers run organizations responsibly and use these powers to deliver the service they sell. The point is that these are real security controls with a real owner, and if the owner is not you, then your answers to questions like “who can grant admin access to our production account?” and “what logs exist and who can delete them?” are incomplete until you have checked.

Three common setups

Reseller arrangements are not all the same. Knowing which one you have saves a lot of confusion.

Setup	Who owns the management account	What you typically control	Where security gaps appear
Marketplace or direct billing, you own the org	You	Everything at the organization and account level	Standard shared-responsibility gaps only
Reseller-billed, reseller owns the org	The reseller	Resources and IAM inside your member accounts	Org-level services, SCPs, billing, and any reseller access role are outside your control
Managed service provider (MSP) operating your accounts	The MSP, often with broad access roles	Whatever the MSP grants you	Operational access, change control, and audit logs depend on the MSP’s processes

The middle row is the one that surprises people, because the accounts feel like yours. You can log in, create resources, and manage IAM. But some of the controls you would reach for during a security review sit one level above where you can see.

What this looks like in practice

Consider a team that decides to eliminate standing administrator access. The plan is sound: use IAM Identity Center with the corporate identity provider, define permission sets, and grant production access only for approved, time-boxed windows. The engineers start to enable Identity Center and AWS stops them with an error saying the management account does not allow member accounts to create instances.

Nothing is broken. This is the model working as designed. Identity Center has two deployment styles:

• An organization instance, enabled from the management account, which can assign permission sets across member accounts. This is what centralized, time-boxed access needs.
• An account instance, which a member account can sometimes create for itself, but which is limited. It supports certain AWS-managed applications and does not provide the multi-account permission assignment that a cross-account access model relies on. The management account can also restrict member accounts from creating these at all.

If the reseller owns the management account and has chosen not to enable Identity Center organization-wide, then the team cannot do the thing they set out to do, and no amount of IAM expertise inside the member account changes that. The responsibility is nominally theirs (“manage your access”), and the capability is held by someone else.

Identity Center is only the most visible example. The same shape appears with organization trails you cannot modify, SCPs that block a service you need, or a security service you cannot enable because its administrator role must be delegated by the management account.

Step one: find out who controls what

You do not need to guess. These checks take minutes, and none of them modify anything.

1. Identify the management account. From any member account with the right to view organization details:

aws organizations describe-organization \
  --query 'Organization.{ManagementAccountId:ManagementAccountId,ManagementEmail:ManagementAccountEmail,FeatureSet:FeatureSet}'

If the management account ID and email belong to your company, you own the organization. If they belong to a reseller or an unfamiliar entity, you do not. If the call is denied, that is also informative: your role may lack organization read permissions, and you should ask the reseller directly.

2. See whether Identity Center exists and where.

aws sso-admin list-instances

An empty list means no instance is visible to your account. An entry whose ARN and identity store you do not recognize may be an organization instance created by the management account owner.

3. Look for organization-level logging you did not create.

aws cloudtrail describe-trails --include-shadow-trails \
  --query 'trailList[].[Name,IsOrganizationTrail,HomeRegion,S3BucketName]'

Organization trails delivered to a bucket in someone else’s account are a normal pattern, and also a question worth asking: who can read those logs, and for how long are they retained?

4. Inventory cross-account access. List roles that trust accounts outside your own:

aws iam list-roles \
  --query 'Roles[].[RoleName,AssumeRolePolicyDocument.Statement[0].Principal.AWS]' \
  --output text

Any role trusting an external account ID needs an owner, a documented purpose, and a review date. Reseller access roles are often broad (“AdministratorAccess” is common) and rarely reviewed.

5. Check the commercial and support basics. Which payment method is on each account? Which support plan applies? Whose email is the root contact? Root contact details matter because the root user can recover access and close accounts.

Step two: ask the right questions

Once you know the setup, convert the findings into a short written request to the reseller. A useful format is a responsibility matrix that both parties fill in. Here is a starting point:

Control	Who owns it today	Can the customer view it?	Can the customer change it?	Notes / change process
Management account root and MFA
SCPs applied to our accounts
IAM Identity Center
Organization CloudTrail and log retention
Security services (GuardDuty, Security Hub, Config)
Reseller or MSP access roles into our accounts
Billing, support plan, credits
Account close and removal
Incident contact and response times

Four questions deserve explicit written answers:

1. Will you enable and delegate the services we need? For example, enabling an organization instance of Identity Center, or delegating administration of a security service to one of our accounts.
2. Can you share the SCPs that apply to us, and give us a change path? A guardrail you cannot read is a guardrail you cannot reason about.
3. What access do you hold into our accounts, and how is it logged and reviewed? Ask for the role names, the permissions, and whether sessions are recorded.
4. What is the process and timeline if we want to leave the organization? Know the answer before you need it.

Step three: choose a path

You have four realistic options. None is universally right; the best one depends on how much control you need and how much the reseller relationship is worth to you.

Option A: stay, and negotiate delegated administration. Many organization-level services support a delegated administrator, where the management account designates one of your member accounts to administer a service for the organization. Identity Center, GuardDuty, Security Hub, and several others support this. The management account still has to enable and delegate, but day-to-day control moves to you. This is the lowest-friction path when the reseller is cooperative.

Option B: stay, and run security from inside your accounts. Everything that works at the single-account level continues to work: CloudTrail in each account, GuardDuty per account, IAM Access Analyzer, Config rules, S3 Block Public Access, and agentless posture tooling that connects with a read-only role. This closes many gaps, though not those that require organization control.

Option C: move your accounts into an organization you own. You create (or already have) your own management account, and member accounts leave the reseller’s organization and join yours. This is the cleanest answer to the control problem and a bigger project; see the next section.

Option D: hybrid. Keep the commercial relationship (billing, support, credits) while moving the technical control plane to you. Some resellers support this through billing arrangements that do not require owning the organization, so it is worth asking.

Moving accounts: what to plan for

Leaving one organization and joining another is well documented and routine, but it has sharp edges. Treat it as a small change project, not a console click.

• Standalone requirements. An account that was created inside the reseller’s organization may not have the information AWS requires of a standalone account: a valid payment method, contact details, and a support plan choice. These must be in place before it can leave.
• Commercial changes. Discounts, credits, support plans, and committed-spend arrangements may be tied to the reseller’s organization and may not follow the account. Get this in writing before you move.
• Guardrails disappear and appear. SCPs from the old organization stop applying the moment the account leaves. If you rely on them for protection, replace them in your new organization first. Likewise, new SCPs you apply later can break workloads that never ran under them, so test.
• Organization-level integrations. Organization trails, Config aggregators, and delegated administrators attached to the old organization will detach. Recreate the equivalents in the new one so you do not create a logging gap during the move.
• Resource sharing. Anything shared through AWS Resource Access Manager at the organization level (subnets, transit gateways, license configurations) can break when accounts leave.
• Cross-account roles. Roles that trust the reseller’s accounts should be reviewed. Decide which stay, which are replaced, and which are removed after the transition.
• Sequencing. Move non-production accounts first, validate, then move production in a planned window. Keep a rollback plan and an emergency contact on both sides.

Our guide on moving between AWS organizations without losing JIT continuity walks through the sequencing in more detail.

What you can do while you wait

The ownership question may take weeks to resolve. Do not wait to reduce risk. Controls you can exercise from a member account include:

• Enable CloudTrail in every account with log file validation, delivered to a bucket your own account controls, in addition to any trail the reseller maintains.
• Turn on account-level GuardDuty and IAM Access Analyzer.
• Remove standing IAM users and long-lived access keys. Replace them with federated access where possible, and rotate or delete what remains.
• Enable S3 Block Public Access and EBS default encryption at the account level.
• Review the reseller’s access role and tighten what you can: a permission boundary on your side, alerts on its use, and a contractual commitment to notify you of sessions.
• Connect posture and identity visibility with a read-only role. This needs no organization ownership.

Where Cloudanix fits

Cloudanix is built so that the work you can start immediately does not depend on who owns your organization, while the work that does depend on it is clearly identified.

• Posture and identity visibility start per account. Cloudanix CSPM and CIEM onboard through a read-only role created by a CloudFormation template, so you can see misconfigurations, over-privileged identities, and the cross-account trust relationships described above without any change to the organization. If you need to limit what is connected in a large organization, our guide on OU-based versus account-based onboarding explains the options.
• Time-boxed access needs an identity layer you control. Cloud JIT works by assigning and removing access in IAM Identity Center (or another supported identity provider) for an approved window. That requires an Identity Center organization instance, which is enabled from the management account. If your reseller owns it, the first step is the conversation and the decision above. We have written separately about integrating JIT with AWS Identity Center.
• Database access without shared passwords. Database JIT runs a proxy service inside your own account, so it does not depend on organization-level settings, though the Identity Center identity layer still feeds who is allowed to request access.

The practical advice is to start with visibility now and settle ownership in parallel, so that when the identity layer is ready, enforcement is a configuration step and not a project.

A one-page checklist

Print this and run it this week:

1. Run describe-organization and write down who owns the management account.
2. Confirm who is on the root contact for every account.
3. List organization-level services in use and whether you can administer them.
4. Obtain the applied SCPs and a change path.
5. Inventory roles that trust external accounts. Document purpose and owner for each.
6. Confirm where organization logs go, who can read them, and how long they are kept.
7. Write down the exit process and its timeline, in the reseller’s own words.
8. Decide A, B, C, or D, and record the reason.
9. Turn on the account-level controls you can enable today.
10. Review again each time the commercial relationship changes.

Closing thought

The shared responsibility model is a good teaching device and a poor audit artifact. An auditor, a regulator, or an incident responder will not ask which half of a diagram you sit on. They will ask who could change a setting, who did, and what record exists. If the honest answer includes a company you have never mapped, the diagram needs a third line, and the model needs a fourth party.

Mapping that party takes an afternoon. Leaving it unmapped means discovering the gap during the worst possible week.

If you want a second pair of eyes on your account structure, talk to us. We will walk through what you can see today, what depends on organization control, and the quickest sequence to get to time-boxed, audited access.

Related Resources

• The Multi-Tenant Blind Spot: When One Team’s Identities Leak Into Another’s Access Portal
• AWS Account Migration and JIT Continuity: Moving Accounts Between Organizations Without Losing Access Control
• Access Handoffs: The Security Gap Nobody Plans For When a Cloud Account Changes Hands
• What Is Shared Responsibility Model
• What Are Cloud Security Fundamentals?
• JIT Access When Your AWS Org Sits Under a Billing Partner and Identity Center Won’t Enable
• Designing Security for GenAI: Guardrails, Shared Responsibility, and Defense in Depth with Shweta Thapa
• Cloudanix Cloud JIT
• Cloudanix CSPM