Security

Your files never leave your own server.
This is what protects them.

Signing in

Sign in with LDAP, Active Directory, OpenID Connect, SAML, ADFS, Shibboleth, Microsoft Azure, OAuth2 or Authentik. Use the one your organization already has.
OpenID Connect reaches Keycloak, Authentik, Authelia, Microsoft Entra ID, Google and any other provider that follows the standard. Signing out ends the session at both ends.
Passkeys: a fingerprint, a face, a device PIN or a USB security key. A passkey cannot be guessed, and it cannot be taken from a leaked database, because the server never holds anything that opens the account.
Two-factor authentication uses the TOTP standard, so any authenticator app works.
One-time recovery codes cover the loss of a device.
Passwords are stored using Argon2id.
Apps, WebDAV clients and sync clients connect with their own named passwords. Lose a device, and you revoke that one entry and nothing else.

A second factor is on by default. FileRun e-mails a code, so the protection does not wait for every user to set up an authenticator app.
Administrators can make a second factor required, and prevent the user from turning it off.
Every change that affects the security of an account is confirmed with the strongest method that account has, in this order: passkey, authenticator app, e-mailed code, password.
A Sessions panel lists every active sign-in, and revokes any of them.
After five failed two-factor attempts, the account is deactivated automatically.
After a failed sign-in, the next attempt is slower. The account is not locked. After ten attempts, one try is allowed every thirty minutes.
Allow an account to sign in only from certain addresses. Use a wildcard, a CIDR range, or a first and last address.
Changing a password signs out every other session. Resetting one also removes every app password and every connected app.

Permissions

Seven roles, applied with one click: Viewer, Commenter, Editor, Contributor, Distributor, Content manager and Uploader. They run from view-only up to full control of the contents.
The web interface, WebDAV, desktop sync, mobile and the API all use the same permission checks. What is not allowed in the browser is not allowed anywhere else.
Each way of connecting can be turned off separately.

For new accounts, link sharing, guest sharing and file history start turned off.
Guest accounts cannot sync, cannot use the API, and cannot share files themselves. They are deleted when their last share is removed.
You can hide all other users from a user completely.

Knowing what happened

Every action is saved with the IP address and the program that made it.
Each entry keeps the name of the user who acted, even if that account is later renamed or deleted.
The history of a file is kept even after the file is deleted.

Actions that failed are saved too, together with the reason why they failed.
When somebody downloads a file through a shared link, you can see all three people: who downloaded it, who created the link, and who shared the file first.

Answering an auditor

A second factor can be required for every account, and the user cannot turn it off.
Group changes, role changes, e-mail address changes and automatic account cleanups are all recorded.
What the software does on its own is filed under a separate System account, so an automatic change is never recorded as the act of a person.

An account can be limited to certain addresses, and every sign-in, failure and refusal is recorded with the address it came from.
An account that has not been used for a set period can be deactivated, and then deleted. Both steps are written to the log.
Access control, multifactor authentication, logging and retention are what a NIS2 assessment and a cyber-insurance questionnaire ask about. These settings are where you answer them.

The server itself

Files are never stored in the database. They stay normal files, on normal disks, in folders you choose.
The documentation explains how to make the server safer: keep user folders outside the web folder, and stop PHP from running where it is not needed.
There is an official Docker image. It is small, it needs few server resources, and everything inside it is already configured. It includes the latest version of each component, it is maintained closely, and FileRun runs fast on it.
Name the addresses of your own proxies, and a visitor can no longer choose the IP address that reaches the activity log and the address restrictions.
Runs on the current PHP, up to and including PHP 8.5.

Except during updates, the database user does not need permission to change or delete tables.
Updates are installed only when you start them, from the control panel. Nothing is installed automatically.
An update that stops partway restores every file it had replaced. The step between replacing the files and updating the database is sealed with a one-time key, so nobody else can finish an update you started.
The programs used for thumbnails and previews (FFmpeg, ImageMagick, vips, LibreOffice, Apache Tika) are started directly, each argument passed on its own. Nothing written in a path or an argument reaches a shell.
If you use an editor on your own server, documents never leave your network.

Check it against your own rules

Put FileRun on your own server with a trial license and hand it to whoever signs off on security.
Or open our live installation, where you are signed in as the administrator with no sign-up.

Request a free trial Open the live demo

Also worth reading: how FileRun uses the systems your organization already has.

Security

Signing in

Permissions

Knowing what happened

Answering an auditor

The server itself

Check it against your own rules

Product

Use cases

Buying

Resources

Company