Bucket policies are the primary control for broad access decisions across buckets and accounts. ACLs are narrower and apply at the bucket or object level, which makes them useful for specific cross account or legacy cases. Most teams should treat ACLs as a supplementary control, not the main access model.
Bucket policies set the default shape of access, while ACLs handle older object-level exceptions
S3 access control is often understood most clearly by separating who defines the rule and how broadly that rule applies. Bucket policies are the modern, centrally managed way to express permissions for a bucket and the objects inside it, especially when access spans accounts or needs conditions such as source IP, encryption requirements, or principal constraints. ACLs are older and narrower, so they are mainly useful where a specific bucket or object needs a simple grant that does not fit the broader policy model.
OWASP Non-Human Identity Top 10 is relevant because S3 permissions are often exercised by workloads, automation, and other non-human identities rather than by people. That matters when teams need to understand not just who can reach a bucket, but which machine or application identity is actually authorised to do so. In practice, many security teams only discover ACL dependence when a legacy integration or cross-account object share keeps working after the intended policy model has already changed.
How bucket policies and ACLs behave differently in real access decisions
Bucket policies are evaluated as part of the bucket’s access rules and are usually the place to express the organisation’s intended control posture. They can allow or deny access based on account, role, action, resource path, and conditions, which makes them suitable for governance at scale. That is why they are better for standardising access across many teams and many objects: the rule is easier to review, log, and reason about than a collection of ad hoc grants.
ACLs, by contrast, are attached at the bucket or object level and are much less expressive. Their main value is compatibility. For example, a legacy workflow might still depend on an object being readable by another account, or on an upload process that expects object ownership or write permission to be set in a particular way. This makes ACLs useful in narrow cases, but also harder to govern because the permission may live closer to the object than to the policy decision makers.
A useful way to compare them is by control intent:
- Bucket policies answer: what access should this bucket or object namespace allow under normal governance?
- ACLs answer: what simple grant or exception must remain in place for a specific bucket or object?
- Bucket policies are better for conditional, auditable decisions.
- ACLs are better for compatibility, not for building the primary access model.
NIST Cybersecurity Framework 2.0 is useful here because the distinction is really about access governance, not storage syntax. Teams should want one clearly owned policy layer and only limited exception handling below it. Where organisations mix both casually, access reviews become unreliable because the effective permission set is split across two mechanisms with different visibility. The guidance breaks down where ACLs are still required for a specific integration or ownership scenario that the policy layer cannot yet replace cleanly.
Why the ACL model becomes fragile as environments and identities scale
Tighter access control often improves governance, but it also increases the cost of exception handling, requiring organisations to balance standardisation against legacy compatibility. That tradeoff is why ACL-heavy S3 estates tend to age badly: every object-level exception becomes another place where ownership, replication, and access review can diverge from the intended policy.
The main edge case is cross-account sharing. A bucket policy can usually express that relationship more cleanly, especially when the target is a role or account boundary rather than a single object grant. ACLs can still work, but they are less transparent to reviewers and less helpful when you need to prove that access was intentional, current, and constrained. Another edge case is object ownership in multi-writer patterns, where ACL behaviour may still matter even if the broader team prefers policy-based control.
CIS Controls v8 fits this discussion because the practical issue is access minimisation and account governance. ACLs are not inherently insecure, but they are easier to leave behind after a migration, easier to overlook in review, and easier to misread as harmless legacy detail. When teams still rely on them, they should treat that as a managed exception and not as an equally strong alternative control.
Where this guidance breaks down is in environments that still depend on object ownership quirks or third-party upload workflows that cannot be reworked immediately.
Risk and Threat Considerations
The main risk is permission drift. When bucket policies define the intended model but ACLs still exist as side paths, access can remain effective even after teams believe they have removed it. That creates a governance gap, especially when object-level grants are inherited, copied, or forgotten during migration.
Failure mechanism: ACLs can preserve access through legacy cross-account grants or object-specific permissions that sit outside the main policy review path. Attackers do not need a special exploit to benefit from that weakness; they only need a reachable identity, over-permissive object access, or an organisation that has not fully retired older control paths.
Impact: The result can be unintended read, write, or overwrite access to objects, weaker auditability, and a false sense that the bucket is tightly governed when some permissions still live elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | S3 access control maps directly to managing and limiting account permissions. |
| Recommendation — Enforce least privilege and remove unnecessary ACL-based access paths. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Access Management | The question is about governing access decisions across identities and resources. |
| GV.OV-2 — Oversight of cybersecurity risk | Mixed bucket-policy and ACL models create governance and review risk. | |
| Recommendation — Centralise access decisions and review effective permissions across policy layers. Establish ownership for exception controls and track legacy ACL use as a governance risk. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | S3 access is often exercised by workload identities and their credentials. |
| Recommendation — Inventory machine identities that can reach S3 and remove stale object-level grants. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Over-permissive ACLs can preserve or alter access relationships on objects. |
| Recommendation — Hunt for unexpected permission persistence and review object-level grants as access manipulation. | ||
Practitioner Guidance
What to prioritise: Treat bucket policy as the primary access decision layer and review ACLs as exception handling. If ACLs are still enabled, the first question is whether they are supporting a real legacy dependency or simply persisting by accident.
What to verify: Confirm that the effective permissions you see in review match the actual access path used by workloads and cross-account principals. The common mistake is checking the bucket policy alone and assuming the object-level story is complete.
Decision rule: If a bucket can operate without ACL-specific grants, simplify to policy-based control and remove the exception path. If a business process still depends on ACLs, document the dependency, assign ownership, and set a removal target rather than normalising the exception.
Practitioner takeaway: The operational difference is not just expressiveness, but governability: bucket policies are where teams should define intent, while ACLs should only survive where a concrete compatibility need can be justified and monitored.
Related resources from NHI Mgmt Group
- What is the difference between static ACLs and context-based access control?
- What is the difference between secrets rotation and access control for non-human identities?
- What is the difference between identity governance and ITSM for access control?
- What is the difference between just-in-time access and role-based access control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
