Access Revocation

Ending access requires changing the credential, session, or account that authorizes it. Signing out of one session, changing a password, and disabling an account have different effects because an account can have several independent ways to connect.

The Access You Need to End

For a lost device, ending that device's connection can preserve the person's other work. For a retired integration, deleting its dedicated credential can stop that integration without disabling the account used by others. For a departing person, disabling the user addresses access through all credentials tied to that account. These are different outcomes, so identify the account, credential, and resource ownership before selecting an action.

An account can also have authority over resources that continue independently, including site-owned workflows and shared links. Removing the account's access and retiring its business processes are separate tasks.

Scope of Access Removal

Sign In with Files.com for Remote MCP creates an ordinary login session, so the account controls that invalidate other login sessions also apply to it. The session follows the site's Session Expiration setting and is also limited by the OAuth application's expiration. When the application has no expiration, the site's session timeout determines the lifetime.

API keys have their own expiration and can be revoked individually, allowing one integration to be stopped without interrupting others. A site-wide key belongs to the site, so disabling the administrator who created it does not revoke it. A user key depends on its associated user remaining enabled.

Changing a password does not replace those separate credential controls. An application holding a valid API key can authenticate again even if a previous login session was invalidated. Disabling the user stops access through that user's credentials; deleting the individual credential stops access through that credential.

SSO and Account Deactivation

Disabling an account at your identity provider prevents future authentication there. Automated provisioning or Files.com user administration must also deactivate the corresponding Files.com account to end its access. API keys and SSH keys do not contact the identity provider each time they are used.

Disabling an SSO integration in Files.com prevents new sign-ins through it and invalidates existing login sessions for users assigned to that provider. It does not delete those users or revoke their separately issued API and SSH keys.

Expiration and Shared Access

Reducing Desktop App Session Lifetime or Mobile App Session Lifetime affects newly issued credentials for that app only. Existing credentials retain their expiration, so reducing either setting, even to 0, does not immediately end current app access. A value of 0 makes new sessions for the selected app expire immediately. Reconnecting with the same credential does not apply the new lifetime. To end an existing Desktop connection, use Active Desktop Connections.

Share Links have their own access controls and visitor sessions. Disabling or deleting a user leaves the links they own available by default. The automatic revocation setting revokes links owned by that user when their account is disabled or deleted. Group-owned links remain available, including links the departing user created, so the remaining group members can keep managing them. Enabling invitation access control on an existing link restricts new access; revoking the Share Link ends existing visitor access.

Permission Removal and Existing Resources

The S3-Compatible Endpoint permission controls S3 access independently of Web, Desktop App, and API. To end a user's S3 access, remove all applicable S3 grants from the user and their groups; on groups-only sites, only group grants count. This blocks S3 use without deleting the keys or changing other protocol permissions. Delete a key when the intended result is to revoke that credential permanently.

Removing a folder permission changes the user's own access, but other grants through groups may still provide access. Check Access shows the effective result. Review the full set of grants when the outcome must be no further access to a folder.

Exports belong to their creator and remain accessible to that user through the site for their 30-day lifetime. Removing Site Administrator privileges or folder permissions does not end access to exports already created. Disabling or deleting the user ends that access.

Snapshots preserve independent copies made while the creator had access. The creator can continue listing and reading the snapshot's folder after losing permission to its source folders. That access lasts for the snapshot's lifetime: until the 96-hour cleanup of an unfinalized snapshot, its expiration date if one is set, or deletion by a Site Administrator. Removing source-folder permissions does not remove the copy; deleting the snapshot ends access to it. Disabling the creator still blocks their account access.

Disabling or deleting a user, or removing the permissions needed for an operation, prevents new requests that depend on that access. A background copy, move, or delete that Files.com accepted before the change may still run to completion. Reversing its effects requires separate action on the affected files and any Share Links over the destination.

Email notifications continue after folder permission is removed until the notification is deleted or the recipient unsubscribes. Disabling the user stops notification emails, including Share Link notifications, even when those notifications remain configured. Re-enabling the account allows notification emails to resume. Share Links also have their own lifecycle. Account and folder changes therefore do not replace reviewing published links, notification recipients, and workflow ownership.

Removing Group Admin or Partner Admin access ends that delegation but does not undo accounts, memberships, or other changes that administrator already made. Ending delegation includes reviewing those lasting effects.

Open FTP and SFTP Connections

An open FTP or SFTP connection detects a password change, deletion of the SSH key used to connect, or a change to the user's root folder on the first subsequent command that interacts with the Files.com API. Until that command, the connection can remain open and answer commands that do not make an API request. Sending a command does not necessarily trigger a check of the current credential, session, or root folder.

Some commands reuse information the connection already received instead of requesting the same information again. For example, repeating ls on an open SFTP connection can return the same cached directory listing after any of these changes. That listing contains information obtained before the change. Seeing it again does not establish that the connection can retrieve new information or authorize another file operation.

FTP and SFTP Root Folder Changes

A user's root folder determines which folder appears as / in their connection. Changing that root changes how the client's paths are interpreted. The first subsequent command that interacts with the Files.com API detects the changed root and causes Files.com to disconnect the existing FTP or SFTP connection. That command can return an error before the connection closes. The client must reconnect to continue with the new root.

The setting appears as User Root when the user's File System Layout is User Root, or as FTP/SFTP Client Root Folder for other layouts. Disconnection applies when the change alters the connection's effective root. Reconnecting uses the new root and remains subject to the user's folder permissions; changing the root does not grant access to its contents.

Downloads Already Authorized

Revocation applies when Files.com next checks the affected credential or session. On an open FTP or SFTP connection, that check occurs when a command interacts with the API. A temporary download URL already issued for a Files.com-hosted file has its own expiration and can remain usable after the login session ends. Ending a session therefore does not guarantee that every previously authorized transfer stops immediately. Files already downloaded remain with their recipient.