Compliance

Enforce a root directory on EFS access points

Security Hub EFS.3 — an access point that points at `/` hands every client the whole file system; pinning it to a subdirectory is the cheapest blast-radius control you'll ever ship.

11 min·10 sections·AWS

Last reviewed 27 May 2026

Remediates AWS Security Hub: EFS.3

EFS access point root directories: the basics

Why an access point that defaults to `/` is a finding

An EFS access point is an application-specific door into a shared Elastic File System. Each access point can pin a POSIX user, a POSIX group, and — critically — a root directory. When you set that root directory to a subdirectory like /app1, every NFS client mounting through that access point sees /app1 as its / and physically cannot traverse up into the rest of the file system. Set it to / and you've created a door with no walls: the client gets the entire shared file system, every other tenant's data included.

Security Hub control EFS.3 checks exactly this. The control fails when the access point's Path is set to /, the default root directory of the file system. It's a Medium-severity control in the Protect > Secure access management category, mapped to NIST 800-53 AC-6(10) — the principle of least privilege. The check is change-triggered, so it re-evaluates whenever an access point is created or modified.

It's flagged because access points are usually created to scope access, and an access point left at / quietly defeats its own purpose. Teams add an access point thinking they've isolated an application, never set RootDirectory.Path, and end up with the isolation theatre of a named access point that grants exactly the same reach as mounting the raw file system. The finding exists to catch that gap before a misconfigured Lambda or container reads or writes data it was never meant to touch.

In this lesson you'll learn what an EFS access point actually enforces, why a root directory of / triggers Security Hub EFS.3, and how access points isolate tenants on shared storage. You'll see the CLI to find non-compliant access points and to create a properly scoped replacement, the under-the-hood detail of how the NFS chroot and CreationInfo auto-provisioning work, and why access points are immutable — meaning the fix is always create-new-then-migrate, never edit-in-place.

Fun fact

The access point that was a door to nowhere — and everywhere

EFS access points were launched in 2020 specifically to solve the multi-tenant problem: before them, every client mounting a file system saw the same root, and you enforced separation entirely through POSIX permissions and careful mount commands. The access point's root-directory enforcement is a true NFS chroot — the client literally cannot express a path outside its assigned subtree, because to that client the subtree is the root. The irony EFS.3 catches is that the one field that makes an access point worth having, RootDirectory.Path, is optional and defaults to /. So the most common misconfiguration is an access point that does everything except the one thing access points were invented for.

Scoping an access point in action

Devon, a platform engineer, gets a new Security Hub EFS.3 finding after a teammate added an access point to the shared analytics-fs file system for a new reporting service. The access point was created with a POSIX user set but no root directory, so its Path is / — the reporting Lambda can see every team's data on the file system, not just the /reports subtree it needs.

Devon can't just edit the access point — EFS access points are immutable; RootDirectory is fixed at creation. So the fix is to create a new access point scoped to /reports, point the reporting service's mount config at the new access point ID, verify the Lambda still reads and writes correctly, then delete the old /-rooted one. The CreationInfo block lets the new access point auto-create /reports with the right ownership if it doesn't already exist.

Ten minutes later the new access point is live, the Lambda's efs_config references the new ID, a smoke test confirms it reads /reports and gets permission-denied on a sibling path, and the old access point is gone. Next Security Hub evaluation, the finding clears. Devon adds the file system to the team's IaC module so future access points come with a non-root RootDirectory.Path by default.

First, list the access points on a file system and check each one's RootDirectory path. Anything showing / will fail EFS.3.

$ aws efs describe-access-points --file-system-id fs-0a1b2c3d4e5f67890 --query 'AccessPoints[].{Id:AccessPointId,Path:RootDirectory.Path,Uid:PosixUser.Uid}' --output table

-----------------------------------------------------------------

| DescribeAccessPoints |

+----------------------+-------------------+--------------------+

| Id | Path | Uid |

+----------------------+-------------------+--------------------+

| fsap-0reports11aa22 | / | 1001 |

| fsap-0ingest33bb44 | /ingest | 1002 |

| fsap-0archive55cc66 | / | 1003 |

+----------------------+-------------------+--------------------+

# Two access points rooted at / — both fail EFS.3 and need scoped replacements.

Any access point with a Path of / exposes the whole file system and trips the control.

Create a replacement access point scoped to a subdirectory. CreationInfo lets EFS provision the directory with the right ownership if it doesn't exist yet.

$ aws efs create-access-point --file-system-id fs-0a1b2c3d4e5f67890 --posix-user Uid=1001,Gid=1001 --root-directory 'Path=/reports,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=0750}' --tags Key=Name,Value=reports-scoped

{

"AccessPointId": "fsap-0reports99zz88",

"FileSystemId": "fs-0a1b2c3d4e5f67890",

"RootDirectory": {

"Path": "/reports",

"CreationInfo": { "OwnerUid": 1001, "OwnerGid": 1001, "Permissions": "0750" }

"LifeCycleState": "creating"

}

# New access point is scoped to /reports — point the app at this ID, then delete the old one.

Create-new is the only path: access points are immutable, so you replace rather than edit.

EFS access points under the hooddeep dive

An EFS access point is a managed NFS entry point that the EFS service enforces server-side. When a client mounts through an access point, EFS applies three overrides on every request regardless of what the client asks for: it can override the POSIX user and group (PosixUser), and it presents the configured RootDirectory.Path as the client's filesystem root. That last one is a true chroot — the access point translates the client's / to the subdirectory, and there is no path expression the client can construct to escape it. This is why EFS.3 cares only about Path: when it's /, the chroot is to the file system root, which is no isolation at all.

The RootDirectory object has two fields. Path is the subdirectory the access point exposes as root. CreationInfo (OwnerUid, OwnerGid, Permissions) tells EFS to create that directory with the specified ownership and mode if it doesn't already exist when the access point is first used — without it, mounting fails if the path is missing. The control fails strictly on Path == "/"; any non-root path passes, which is why even a shallow /app is compliant.

The operational gotcha is immutability. Neither RootDirectory nor PosixUser can be modified after creation — there is no update-access-point API. Remediation is therefore always: create a new, correctly-scoped access point, repoint every consumer (Lambda FileSystemConfig, ECS volume authorizationConfig.accessPointId, EC2 mount helper accesspoint= option) at the new ID, validate, then delete-access-point on the old one. There's no in-place fix, so the IaC fix and the live fix are the same shape.

# Find every access point across the account that fails EFS.3 (Path == "/").
for fs in $(aws efs describe-file-systems --query 'FileSystems[].FileSystemId' --output text); do
  aws efs describe-access-points --file-system-id "$fs" \
    --query "AccessPoints[?RootDirectory.Path=='/'].[AccessPointId,FileSystemId]" \
    --output text
done

# After repointing all consumers to the scoped replacement, remove the non-compliant one.
# (Access points are immutable — there is no update API; delete is the only retirement path.)
aws efs delete-access-point --access-point-id fsap-0reports11aa22

What is the impact of an unscoped EFS access point?

The direct impact is blast radius. An access point rooted at / gives whatever mounts through it visibility of the entire file system, not the subdirectory the application needs. On a shared file system holding data from multiple applications or tenants, that means one compromised or misconfigured consumer — a Lambda with an over-broad role, a container that got popped, a developer who copied a mount config — can read, and often write, across data it has no business touching.

Combined with the POSIX user override, the risk sharpens. If the access point also enforces a privileged UID (or no specific UID), a client reaching the root of the file system can manipulate other applications' files at the filesystem level. EFS.3 is mapped to NIST 800-53 AC-6(10), least privilege, precisely because the access point is supposed to be the enforcement point that confines an application to its own data — and an unscoped one is enforcement that enforces nothing.

There's a compliance and audit dimension too. Because the control is change-triggered, a single careless access point creation flips the control to FAILED almost immediately and it shows up on the next posture report. For organisations tracking a compliance framework, an open EFS.3 is a least-privilege control failure that has to be either remediated or formally accepted as an exception — neither of which is free in audit time, even though the fix itself is cheap.

Finally, there's the silent-isolation-failure cost. Teams create access points believing they've partitioned a shared file system. If those access points are rooted at /, the partitioning is illusory — the architecture diagram says "isolated tenants" while the runtime says "everyone sees everything." That gap between intended and actual isolation is exactly the kind of thing that surfaces at the worst possible moment, during an incident, when someone discovers the boundary they relied on was never there.

How do you remediate and prevent EFS.3?

Because access points are immutable, every fix is a replace-not-edit operation. The loop is: find the unscoped access points, create scoped replacements, repoint consumers, retire the old ones, and add a guardrail so it can't recur.

1. Inventory every access point rooted at `/`

Iterate every file system in every region and list access points where RootDirectory.Path == "/". These are your EFS.3 failures. Capture the access point ID, file system ID, and the PosixUser so the replacement matches the original's identity enforcement. Note which consumers reference each ID — Lambda functions, ECS task definitions, and EC2 mounts all bind to a specific access point ID, and you'll need that list to repoint cleanly.

2. Create a scoped replacement with CreationInfo

For each failing access point, create a new one with a non-root RootDirectory.Path (e.g. /app1) and a CreationInfo block specifying OwnerUid, OwnerGid, and Permissions so EFS provisions the subdirectory with correct ownership if it doesn't exist. Carry over the same PosixUser as the original. Any non-root path passes the control, but choose a path that genuinely scopes the application to its own data — the point is isolation, not just passing the check.

3. Repoint consumers, validate, then delete the old access point

Update every consumer's mount configuration to the new access point ID — Lambda FileSystemConfig.Arn, ECS volume authorizationConfig.accessPointId, or the EC2 mount helper's accesspoint= option. Run a smoke test that confirms the application can read and write its own subtree and gets permission-denied on a sibling path. Only after validation, run delete-access-point on the old /-rooted one. Never delete first — there's no rollback once it's gone, and consumers will fail their mounts.

4. Add a guardrail so it can't recur

Bake a non-root RootDirectory.Path into the IaC module every team uses to create access points, so the compliant configuration is the default. Back it with a preventive control — an SCP or IAM condition, or an AWS Config rule (efs-access-point-enforce-root-directory) wired to alerting — so an access point created at / is either blocked or flagged immediately rather than waiting for the next posture report. Prevention is what keeps the control green by construction.

# 1. Create the scoped replacement (matches the original PosixUser, adds CreationInfo).
NEW=$(aws efs create-access-point \
  --file-system-id fs-0a1b2c3d4e5f67890 \
  --posix-user Uid=1001,Gid=1001 \
  --root-directory 'Path=/reports,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=0750}' \
  --tags Key=Name,Value=reports-scoped \
  --query 'AccessPointId' --output text)
echo "New access point: $NEW"

# 2. Repoint the Lambda consumer at the new access point, then validate before deleting.
aws lambda update-function-configuration \
  --function-name reporting-svc \
  --file-system-configs Arn=arn:aws:elasticfilesystem:us-east-1:111122223333:access-point/$NEW,LocalMountPath=/mnt/reports

# 3. Only after a successful read/write smoke test, retire the non-compliant access point.
aws efs delete-access-point --access-point-id fsap-0reports11aa22

Quick quiz

Question 1 of 5

Security Hub flags an EFS access point with RootDirectory.Path set to /, used by one production Lambda. What's the correct remediation?

Keep learning

Dig deeper into EFS access points, the underlying control, and least-privilege design on shared storage.

You've completed Enforce a root directory on EFS access points. You now know why an access point rooted at / defeats its own purpose, why Security Hub EFS.3 fails on exactly that condition, and the replace-not-edit remediation loop — inventory, create scoped replacement with CreationInfo, repoint consumers, delete the old one — plus the guardrail that keeps the control green. Next time EFS.3 lights up, you'll have a defensible path from flagged to resolved without an in-place edit that doesn't exist.

Back to the library

EFS access point root directories: what it means for risk

A control that limits who can reach what on shared storage

Amazon EFS is shared file storage that many applications can mount at once. An "access point" is a controlled doorway into that storage, and one of its jobs is to confine an application to its own folder rather than letting it see everything stored on the system. Security Hub control EFS.3 fails when a doorway is left wide open — pointed at the top-level folder — so anything using it can reach all the data on that file system, not just its own slice.

This isn't a cost finding; it's a data-access and least-privilege finding. The business risk is straightforward: shared storage often holds data from several applications or teams, and a doorway that isn't confined to a subdirectory means a single misconfigured or compromised application can read or write across all of it. That's the kind of gap that turns a small incident into a reportable one.

The control is rated Medium severity and maps to a recognised least-privilege standard. From a governance standpoint, the right framing is that every access point should be scoped to a specific folder by default, and an unscoped one is a signal that someone set up access without finishing the isolation step. It's cheap to fix and cheap to prevent, which is why it belongs on the compliance dashboard rather than buried in an engineering backlog.

This lesson is for the finance or governance partner who tracks the compliance dashboard and wants to understand what an EFS.3 finding means without learning NFS internals. It covers what the control protects against, why it's a least-privilege issue rather than a cost issue, what "good" looks like, and the two governance levers — a guardrail policy and a standing dashboard line — that keep the count at zero. By the end you'll know what to ask engineering when the number isn't zero, and why "just edit the access point" isn't the answer.

Fun fact

The access point that was a door to nowhere — and everywhere

How a governance partner closes the loop

Priya is the governance partner who reviews the security posture pack each month. The EFS.3 line, which has sat at zero for two quarters, ticks up to one. She doesn't need the technical detail; she needs to know whether it's a real exposure and whether it's being handled. The control summary tells her it's a least-privilege gap on shared storage, Medium severity — an access point that can reach more data than its application needs.

Her conversation with the platform team is short. She asks three things: which application the access point serves, what data lives on that file system besides the application's own, and whether the fix is in flight. The team confirms it's a single reporting service, the file system is shared across three teams, and a scoped replacement is already being rolled out. That's enough — real but contained, and being remediated.

Priya's follow-up isn't about this one finding; it's about why it happened. The team agrees to add a guardrail so new access points can't be created at / without an exception. Next month the line is back to zero and stays there. Priya treats the recurrence count, not the absolute number, as the metric: one finding fixed quickly is healthy; the same control reopening month after month means the guardrail isn't in place and that's the conversation.

Why this matters to risk, not the bill

This control has no direct dollar cost — fixing it doesn't reduce a bill and leaving it open doesn't increase one. Its impact is risk exposure, and the right lens is least privilege: how much data can a single application or identity reach beyond what it needs? An access point rooted at the top of a shared file system answers "all of it," which is the opposite of what a controlled access point is meant to provide.

The material cost shows up in two places. The first is incident severity: if shared storage holds data from multiple teams or customers and an access point isn't confined to one folder, a single compromised component can turn a contained incident into a cross-tenant data exposure — the kind that triggers breach notification obligations and regulatory attention. The second is audit overhead: an open Medium-severity least-privilege finding against a recognised framework must be remediated or formally accepted, and exceptions carry their own review and sign-off cost.

Because the fix is cheap and the prevention is a one-line policy, this is a high-return control to keep green. The cost of a guardrail is near zero; the cost of explaining an unscoped access point during a customer security review or an audit is not. Treat it as a hygiene control whose value is measured in incidents and audit findings avoided, not dollars saved.

What governance can actually do about this

Governance can't create access points, but it can make the unsafe configuration impossible and keep the control visible. Two levers, used together.

1. Make the scoped configuration the only path

The single highest-leverage move is a preventive guardrail — a policy or Config rule that blocks or flags any EFS access point created at the root directory. Pair it with a shared IaC module that ships with a scoped root by default. Once the safe configuration is the default and the unsafe one is blocked, this control stays green without anyone having to chase it.

2. Keep it as a standing line on the posture report

Track EFS.3 on the monthly security posture pack with both the current count and how many times it's reopened in the trailing quarter. A finding that opens and closes once is normal operations; a control that reopens repeatedly means the guardrail isn't in place, and that's the escalation trigger — not the absolute count.

3. Require remediate-or-accept, never ignore

Because this maps to a recognised least-privilege standard, every open finding should be either remediated within an agreed window or formally accepted as a documented exception with a named owner. "Open and unaddressed" is the state to eliminate. The exception path exists for genuine cases, but it should cost a signature, so the default is to fix.

4. Ask the architecture question, not just the finding question

When a finding appears, the useful question for governance isn't "is it closed?" but "what data sits on that shared file system, and who else can reach it?" That reframes a checkbox into a real risk assessment and surfaces whether the broader isolation model on shared storage is sound — which is the thing the control is really a proxy for.

Quick quiz

Question 1 of 5

The EFS.3 line on the posture report has reopened in three of the last four months — each time a finding is fixed within days, then a new one appears. As the governance partner, what's the right read and move?

Keep learning

Dig deeper into EFS access points, the underlying control, and least-privilege design on shared storage.

You've finished the governance view of EFS.3. You know it's a least-privilege control on shared storage rather than a cost finding, why its real cost is incident severity and audit overhead, and the two levers that matter — a preventive guardrail plus a default-safe IaC module, and treating recurrence (not the snapshot count) as the metric. Next time the line moves, you'll have a sharper question than "is it closed yet?"

Back to the library

EFS access point root directories: the headline

Shared storage that isn't partitioned the way it should be

Amazon EFS is shared file storage. Access points are the controlled entry points into it, and best practice is for each one to be confined to its own folder so an application can only touch its own data. This control flags entry points that were left pointing at the top of the file system, where they can reach everything.

This is a least-privilege and blast-radius issue, not a cost one. The fix is small and the prevention is a one-line policy. What matters at the leadership level is that the control stays green: a recurring or growing count here means teams are standing up shared storage without finishing the access-isolation step, and that pattern tends to show up in other security findings too.

A short read for the executive who sees EFS.3 on the security posture report and wants the headline and the one question to ask. You'll get the plain-English framing of the risk, why it's low-effort to fix and prevent, and what a healthy trend looks like — no commands, no implementation detail.

Fun fact

The access point that was a door to nowhere — and everywhere

What it looks like when the org gets this right

At one company the security posture review used to surface EFS.3 findings sporadically — an access point here, another there, each opened and closed over a few weeks. Small individually, but the pattern told the exec sponsor something: teams were standing up shared storage and forgetting to partition access. She stopped asking about individual findings and started asking about the pattern: "Why can we create one of these at all? What stops the next team from repeating it?"

Within a quarter the answer changed. A guardrail policy blocked unscoped access points at creation, and the IaC modules every team used shipped with a scoped root directory by default. The EFS.3 line went flat at zero and stopped being a recurring agenda item. The exec hadn't asked anyone to chase findings — she'd asked them to make the safe path the default path.

That's the right outcome state. The goal isn't "close this finding fast"; it's "make the misconfiguration impossible to introduce." When a Medium-severity control stays green by construction rather than by cleanup, leadership attention is free to go elsewhere.

Why this is on the report at all

There's no cost number attached to this control. It's tracked because it's a least-privilege measure on shared storage — it confirms that applications can only reach their own data, not everything stored alongside it. An open finding means at least one entry point is over-broad, which raises the severity of any incident involving that storage from "one application's data" to "potentially all of it."

The pattern matters more than any single finding. A control that keeps reopening signals that teams are building shared infrastructure without finishing the isolation step — and that habit rarely stays confined to one service. The leadership move is to ask whether the safe configuration is the default, because a control that stays green by design costs nothing to maintain, while one that's repeatedly cleaned up by hand is a standing tax and a recurring risk.

The leadership move on this control

The handle for an executive isn't to drive the finding count down by hand — it's to make the unsafe configuration impossible to introduce.

1. Insist the safe configuration is the default

Ask whether a team can even create one of these misconfigured access points. If the answer is "yes, nothing stops them," the fix is a guardrail and a default-safe IaC module, not a cleanup sprint. A control that's green by construction needs no ongoing attention.

2. Watch the recurrence, not the snapshot

A single finding opened and closed is healthy operations. The same control reopening quarter after quarter is the signal worth your attention — it means the preventive control was never put in place and the org is paying a recurring tax to clean up the same mistake.

3. Treat it as a confidence signal on shared-storage hygiene

This control is a small, clear proxy for a bigger question: are teams partitioning shared infrastructure properly? If EFS.3 stays green by design, it's reasonable evidence the isolation discipline is working, and leadership can spend its security attention on higher-severity surfaces.

Quick quiz

Question 1 of 5

EFS.3 has been green for three quarters, and engineering reports a guardrail now blocks any access point from being created at the root directory. What's the right read?

Keep learning

Dig deeper into EFS access points, the underlying control, and least-privilege design on shared storage.

That's the lesson. Two takeaways: an EFS access point left at the root directory means an application can reach all the data on shared storage, not just its own — and the fix and the prevention are both cheap. The leadership question is whether the safe configuration is the default, so the control stays green by design rather than by repeated cleanup.

Back to the library

Enforce a root directory on EFS access points

EFS access point root directories: the basics

The access point that was a door to nowhere — and everywhere

Scoping an access point in action

EFS access points under the hooddeep dive

What is the impact of an unscoped EFS access point?

How do you remediate and prevent EFS.3?

1. Inventory every access point rooted at /

2. Create a scoped replacement with CreationInfo

3. Repoint consumers, validate, then delete the old access point

4. Add a guardrail so it can't recur

Quick quiz

Keep learning

EFS access point root directories: what it means for risk

The access point that was a door to nowhere — and everywhere

How a governance partner closes the loop

Why this matters to risk, not the bill

What governance can actually do about this

1. Make the scoped configuration the only path

2. Keep it as a standing line on the posture report

3. Require remediate-or-accept, never ignore

4. Ask the architecture question, not just the finding question

Quick quiz

Keep learning

EFS access point root directories: the headline

The access point that was a door to nowhere — and everywhere

What it looks like when the org gets this right

Why this is on the report at all

The leadership move on this control

1. Insist the safe configuration is the default

2. Watch the recurrence, not the snapshot

3. Treat it as a confidence signal on shared-storage hygiene

Quick quiz

Keep learning

Related compliance lessons

1. Inventory every access point rooted at `/`