Security at RFF

RFF manages Windows, Mac and Linux machines over the internet. To do that well, you trust us with real power: stored admin credentials, MFA secrets, and the ability to run privileged actions across your fleet. We don’t take that lightly. This page is a plain-English account of how we protect it - written by the people who built it, not a compliance department.

If you find a security issue, please see Reporting a vulnerability below. We read every report.

The short version

• Your sensitive data is encrypted at rest - credential passwords and MFA secrets are never stored in the clear.
• The keys that protect that data are themselves encrypted, wrapped with an X.509 certificate, and the app refuses to start in production if that protection isn’t in place.
• Tenants are isolated at the database query level - not just hidden in the UI. Every query is automatically scoped to the tenant that issued it.
• Every privileged action is written to an audit log - who did what, to which machine, from which IP, and when.
• Traffic is encrypted in transit with TLS, end to end.
• The update channel is guarded end to end. Releases are signed by a human on a hardware token, hash-verified by the agent before install, and rollback-protected on the machine. Paid fleets stay pinned until you approve a move.
• We host it, we patch it, we secure it. There’s no server on your network to harden, expose, or forget about.

How we protect stored secrets

RFF stores two especially sensitive kinds of data: the credentials used to reach your machines and the MFA secrets that protect your account. Both are encrypted at rest using ASP.NET Core’s Data Protection stack with IDataProtector. Plaintext credentials and MFA secrets are never written to the database.

What makes that meaningful (and where a lot of products quietly fall short) is the key management underneath it:

• The key ring is persisted durably, so a routine deploy or container rebuild can’t silently regenerate the keys and lock everyone out - or worse, leave half your data undecryptable.
• The key ring is encrypted at rest, wrapped with an X.509 certificate. A leaked database backup or an over-broad read of the database does not hand an attacker the keys to your credentials.
• We fail closed. If the key-wrapping certificate isn’t configured, RFF refuses to boot in production rather than fall back to storing keys in the clear. Protection you can accidentally turn off isn’t protection.

We wrote up the engineering behind this in detail - including a live, zero-downtime migration to re-encrypt existing data - on our engineering blog. We believe security you can read about is more trustworthy than security you have to take on faith.

Account security

• Multi-factor authentication (TOTP) is supported for accounts, using any standard authenticator app.
• Login is hardened against brute force. Repeated failed attempts are throttled, and authentication is written to run in constant time so an attacker can’t learn whether an email exists by measuring how long a login takes. (We don’t publish the exact thresholds, for obvious reasons.)
• Passwords are stored using bcrypt - a modern, salted, deliberately slow password hash - never reversible, never in plaintext.
• Single sign-on with Microsoft and Google is live. SAML, for teams that bring their own identity provider, is on the roadmap.

Tenant isolation

Every account belongs to a tenant, and isolation is enforced at the data layer - not merely hidden in the interface. Every database query is automatically filtered to the tenant that made the request, so one tenant’s data is structurally unable to appear in another tenant’s results. Running multiple independent client tenants under a single login is live: each client gets its own hard-walled tenant, and you switch between them without logging out. Inside a single tenant you can still separate clients and sites with device groups and Sites, which is the lighter option when the clients aren’t separate businesses. Administrative “impersonation” used by our platform staff for support is scoped, time-limited, and itself audited.

Auditing & least privilege

• Full audit trail. Every privileged action - deployments, remote actions, credential use, configuration changes - is recorded with the actor, target, source IP, and timestamp.
• Role-based access. Users get the access their role requires and no more.
• Scoped credentials. Credentials are used for the specific action that needs them and are never exposed back to the browser.

Infrastructure & data handling

• Encryption in transit. All traffic between your browser, our API, and your agents is protected with TLS.
• Hosted and maintained by us. RFF runs on Render; there is no inbound-exposed server on your network. Agents reach out to us and poll for work - nothing listens for inbound connections on your endpoints.
• Backups. Databases are backed up nightly, and we test that backups restore.
• Data location. RFF’s application and database run in the United States (Render’s Oregon region); object storage is on Cloudflare R2. If your procurement needs a formal Data Processing Addendum, get in touch - we’ll work with you.

The agent on your machines

• Agents poll outbound to RFF on a regular interval (the free tier checks in about every 60 seconds) and execute queued work on their next check-in. They do not open inbound ports or require a VPN back to an office.
• Agents self-update to the version you publish on their next poll, so you’re not manually re-running installers to stay current. How a release gets built, signed, verified, and rolled back is important enough to get its own section - see The update channel just below.

The update channel

For any product in this category, this is the threat model that should worry you most. An agent update pipeline is, structurally, the ability to run code on every machine the product manages - that is how Kaseya’s customers got hit, and no encryption-at-rest bullet answers it. So here is exactly how a release reaches your fleet:

• Every release is signed by a human at a keyboard. The code-signing certificate (issued to Vitko Software, LLC) lives on a hardware token that requires a PIN for each signing session, and the token stays unplugged except during a release. The private key can’t be exported or copied, and no build server holds it - there is no unattended pipeline with signing authority to compromise.
• Signatures are verified before anything ships. Every executable and the installer itself are Authenticode-signed (SHA-256, timestamped), and the build fails hard if any artifact ends up unsigned or its signature doesn’t chain to a trusted root. An unsigned binary can’t slip out the door.
• Publishing is a second, separate act. A signed installer reaches nobody until it’s uploaded through the platform’s own authenticated admin path. The signing key alone can’t touch your fleet, and the platform alone can’t produce a validly signed binary. An attacker needs both.
• Agents verify what they download. Before installing, the updater hashes the downloaded installer and refuses on a SHA-256 mismatch against the published release.
• Paid fleets stay pinned by default. Auto-update is opt-in on paid plans, so your enrolled fleet runs the version you approved until you decide to move. Free agents track the current release, which is part of how we keep Free supportable.
• A bad update reverses itself. Each machine keeps the last-known-good installer cached locally. A watchdog rolls the box back if a new version fails to come up healthy, and it remembers the bad version so it won’t loop back into it.

One thing we haven’t built yet: per-command payload signing, so that even a fully compromised RFF server couldn’t hand an agent an unsigned artifact. It’s on the security roadmap.

Remote desktop sessions

Remote desktop lets an operator take live control of a managed machine from the browser. Because that’s real power, it’s wrapped in the same controls as the rest of the product:

• Attended sessions are consent-gated. When someone is signed in, they see a prompt naming the operator before control begins, then a persistent on-screen banner for the whole session - with a panic key that ends it immediately.
• Unattended access is off by default. Reaching a machine when no one is signed in - for example, to drive the Windows logon screen - must be explicitly turned on by a tenant administrator before it’s permitted.
• Every session is audited. Each session records who connected, to which machine, and how long it lasted, bucketed to the tenant that owns the endpoint - so you always see who reached into your fleet.
• It rides the same encrypted, outbound-only path. Sessions run over the same TLS connection the agent already uses. The agent still only makes outbound connections and opens no inbound ports. File transfer during a session runs as the signed-in user, not SYSTEM, so an operator can reach only what that user could reach by hand.
• Remote control is free; the risky modes are opt-in. Attended remote control (someone signed in) is available on every plan, Free included, and so are unattended access (nobody signed in) and UAC-elevated control. Both stay OFF until an admin turns them on for the tenant, because they are the two capabilities worth a deliberate decision. What Free caps is scale, not capability. It ships in beta while we harden the session transport for the most locked-down corporate networks.

If we go away

A fair question to ask a young vendor, so here’s the answer. RFF is a small company, and you should evaluate it like one. Here’s what that risk actually costs you, with the exit defined up front:

• Leaving takes an afternoon, not a project. The agent is a standard Windows Installer package: mass removal is a silent msiexec /x, scriptable through Group Policy, Intune, or whatever tool you’d replace us with. No proprietary removal utility, nothing left running.
• Your data isn’t hostage. Inventory, compliance, vulnerability, and reporting data export as CSV from the dashboard, and the read API serves your fleet data to anything you point at it.
• A shutdown would come with notice. If we ever wind the service down, you’ll get at least 90 days’ notice and a data-export window before anything turns off.
• The free tier isn’t a loss-leader mystery. Free caps scale (100 endpoints), not features. It’s how a young product earns trust and word of mouth; paid plans price by fleet size and fund the rest.

What we don’t claim

We’d rather be straight with you than impressive:

• We are not SOC 2 / ISO 27001 certified (today). We follow the practices above because they’re right, not because an auditor signed off. If formal certification matters to your procurement process, tell us - it helps us prioritize.
• We’re a young product. That’s exactly why we publish how things work and invite scrutiny, rather than hiding behind a logo wall.

Reporting a vulnerability

If you believe you’ve found a security vulnerability in RFF, please email security@getrff.com. Include enough detail to reproduce it. We’ll acknowledge your report, keep you updated, and we won’t pursue legal action against good-faith research that respects our users’ data and privacy.

Please don’t publicly disclose an issue until we’ve had a reasonable chance to fix it. We’re a small team and we move fast.

We don’t run a paid bug bounty. We fix every valid report anyway, whoever sends it, and we’re happy to credit you when the fix ships. Please test against your own free account, never someone else’s devices or data.

RFF is hosted fleet management for Windows, Mac and Linux - deploy software, automate patching, and run remote actions from a browser. Start free for your first 100 endpoints.