EE Files and Secure Enclave FoundationsLast updated: 6 August 2026

SFS Access works with the native ExpressionEngine Files system. It does not replace EE Files, and it does not require your team to learn a new file manager.

Instead, SFS Access applies governance to EE upload locations and file operations so sensitive workflows are policy-controlled while daily file handling stays familiar.

• EE Files provides the underlying file location and file operations framework.
• SFS Access governs who can operate in secure enclaves and what actions are allowed.

Runtime behaviour in practice

• Upload directory visibility can be filtered by effective member scope.
• Operation decisions are evaluated per member, enclave, and action.
• Policy outcomes are reflected in both Control Panel checks and secure file flows.

This approach improves security without forcing teams into a separate file-management system.

SFS Access requires secure file locations to be above webroot. In simple terms, this means the files are stored outside the part of the site that can be reached directly by a public web URL.

What is an above-webroot location?

• It is a real server folder, not a public website path.
• It sits outside the webroot used to serve public site files directly.
• It is available to EE and SFS Access on the server, but not directly exposed to browser visitors.

Why this matters

• Files stored above webroot cannot be accessed directly by guessing or discovering a public URL.
• This means file access goes through the SFS Access handler, which checks the enclave rules before allowing access.
• In practice, the file is only available when the current user meets the secure access rules defined for that enclave.

When this is checked

SFS Access checks location suitability when you create or assign secure file locations. After that, normal file access continues through the secure SFS Access handling path.

See the file streaming and path security guidance for download-path protections and traversal-safe handling principles.

An enclave is a defined secure area with clear governance boundaries. Boundaries are important because they make access policy explicit, auditable, and easier to maintain.

With clear enclave boundaries, your team can:

• Apply different controls to different sensitivity levels.
• Assign roles with least-privilege access in each enclave.
• Respond faster to incidents by restricting specific enclaves without affecting unrelated areas.

In practical terms, this improves protection and reduces the chance of broad permissions being applied by mistake.

SFS Access is built so authorised users can still complete routine file tasks without a complicated process.

When policy, role, and membership conditions are met, users can work in a familiar EE-style flow for approved operations. When conditions are not met, actions are denied in a controlled and predictable way.

This balance is important:

• Security is stronger because sensitive actions are policy-governed.
• Usability is preserved because routine authorised work remains straightforward.
• Support overhead is reduced because outcomes are more consistent and easier to explain.

SFS Access secures file delivery by checking access rules before a file is returned to the user.

This protects enclave boundaries while keeping normal authorised download workflows usable.

How secure file delivery works

1. SFS Access receives a request for a secure file.
2. It checks whether the user is allowed to access that file.
3. It confirms that the request points to the correct secure file location.
4. The file is delivered only if all checks succeed.

When access is approved, SFS Access issues a short-lived secure delivery link. That link remains valid for a limited time only, so it should be used promptly rather than stored for later use.

In practical terms, this is not usually a traditional shareable link handed to the user for general reuse. It is a short-lived secure delivery request used inside the normal SFS Access flow so the user does not need a fresh approval step for every immediate repeat request within that time window.

If files need to be shared with people who are not authorised users of the site, use the SFS Gateway companion add-on rather than SFS Access delivery links.

How SFS Access keeps delivery safe

• It checks that the request is for a real file in the expected secure location.
• It rejects requests that do not match safe file-location rules.
• It only returns content after access permission and file-location checks both pass.

Common reasons access is denied

• The user does not have permission to access the file.
• The request does not match a safe or valid file location.
• The file cannot be found in the expected secure location.
• The secure delivery request is no longer valid.

Diagnostic sequence

If a user cannot access a file that you believe they should be able to access, work through the following checks.

1. Check the user’s access with Effective Access Check.
2. Confirm the file is in the expected secure upload location.
3. Review Security Activity Log entries for denied access reasons.
4. Retest after policy or membership corrections.

SFS Access controls which file upload locations each member can see in EE Files.

It is normal for different members to see different upload location lists in the same EE Files screens.

How file upload location visibility works

• SFS Access checks which enclaves and roles apply to the current member.
• It limits the visible SFS Access controlled upload locations to only the ones the member is allowed to use.
• The member then sees only those locations in EE Files.

Why lists can differ

• Members can be in different pools and enclaves.
• Members can have different role permissions.
• Lockdown or policy changes can change which locations are available.

Diagnostic checks

If a user cannot see a file upload location that you believe they should be able to use, work through the following checks.

1. Run Effective Access Check for the member and enclave.
2. Confirm active membership and role assignment.
3. Confirm enclave status is active.
4. Review Security Activity Log for recent deny reasons.

Team communication guidance

• Explain that different upload location lists are expected when access rules differ.
• Use the user’s named role and enclave assignment when explaining access outcomes.