Credentials and 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
| Action | Effect |
|---|---|
| Sign out of a web session | Ends that session. Other sessions and independently issued credentials remain separate. |
| Change a Files.com password | Invalidates other existing login sessions. API keys and SSH keys remain issued and can authenticate separately. |
| Delete an API key | Prevents further use of that key, including sessions associated with it. Other keys remain usable. |
| Delete an SSH key | Prevents further authentication with that key and invalidates sessions associated with it. Other credentials remain separate. |
| Revoke a Desktop App connection | Ends that app connection and requires a new sign-in. |
| End access established through Sign In with Files.com for Remote MCP | The login session ends on timeout, OAuth application expiration or revocation, disabling all AI features, or account changes that invalidate login sessions, such as changing the Files.com password or disabling the user. There is no individual OAuth grant revocation control in the Web App. |
| Disable a Files.com user | Blocks the user's authentication and invalidates the user's existing login sessions, including access through user API keys and SSH keys. |
| Revoke a Share Link | Ends visitor access through that Share Link, including existing visitor sessions. |
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/Mobile Session Lifetime affects newly issued app credentials. Existing credentials retain their expiration, so reducing the setting does not immediately end current app access. Reconnecting with the same credential does not apply the new lifetime. The Active Desktop Connections controls revoke an existing Desktop connection.
Share Links have their own access controls and visitor sessions. Disabling a creator leaves their Share Links available by default. The automatic revocation setting connects Share Link revocation to the creator's account status. Enabling invitation access control on an existing link restricts new access; revoking the Share Link ends existing visitor access.
Permission Removal and Existing Resources
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.
Email notifications continue after folder permission is removed until the notification is deleted or the recipient unsubscribes. Share Links also have their own lifecycle. Account and folder changes therefore do not replace reviewing published links, notification recipients, and workflow ownership.
Removing a Group Admin or Partner Admin role ends the delegated role but does not undo accounts, memberships, or other changes that administrator already made. Ending delegation includes reviewing those lasting effects.
Downloads Already Authorized
Revocation applies when Files.com next checks the affected credential or session. 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.