Security

How MoorNest keeps backups safe

A backup is a full copy of a client's data, so it has to be harder to get at than the server it came from. This page describes how MoorNest is built to make that true, and what it doesn't claim yet.

Encrypted before it leaves the server

The MoorNest agent encrypts every block on the client's server, before anything is sent.

• Each object is sealed with AES-256-GCM under its own fresh key. Tampering with a stored block makes it fail to decrypt rather than restore wrong data.
• Each object key is then wrapped with a public key, so the agent can encrypt but can't decrypt. For MoorNest Cloud the matching private key is an RSA key inside AWS KMS that can't be exported. Other destinations use X25519 key exchange.
• Blocks are named with a keyed HMAC-SHA-256, so a block's name says nothing about what is in it.
• The agent gets only what it needs to encrypt: no private recovery key, no storage account credentials, no key service access.

The client's NAS and MoorNest Cloud only ever hold encrypted blocks.

Encrypted in transit

Every connection runs over TLS, never below TLS 1.2. Gateway tunnels and the portal use TLS 1.3. When backups go to a NAS through the gateway, the agent checks the gateway's pinned certificate, so the connection is encrypted end to end even through the tunnel.

Outbound only

Agents and gateways connect out to MoorNest. There is nothing to open on the client's firewall, no port forwarding and no VPN.

A hacked server can't touch the backups

Ransomware usually goes after the backups first. MoorNest is designed so that taking over a server doesn't give access to its history.

• Write-only agent. The agent can add new backups. It can't read, list, change or delete the ones already stored.
• Write-once storage. Nothing is overwritten. In MoorNest Cloud, S3 Object Lock in compliance mode means no one can delete a backup or shorten how long it is kept before its retention period ends. That includes us.
• Restores are separate. A server can't restore anything on its own. See the next section.

The honest limit: if a server is compromised, backups taken after that point may hold damaged files. The ones from before stay intact, so you restore a night from before the attack.

Restores need a person, a password and a code

• Restores start in the console, never from the server.
• Starting one needs an administrator account, its password and a fresh authenticator code. Every change an administrator makes to a workspace with MoorNest Cloud storage needs a fresh code.
• A server can be a restore target only if you have allowed restores for it in the console and it is allowed in the server's own configuration. Servers are backup-only until then.
• After an attack, restore to a clean server rather than the one that was compromised.

Sign-in and team access

• Two-factor sign-in for every account. Authenticator codes (TOTP) are required and can't be switched off. There is no password-only way to reset them.
• Trusted browsers. You can skip the code on a browser you trust for 30 days. That browser still needs the password, and administrator changes still ask for a fresh code.
• Password storage. Passwords are kept as salted PBKDF2-HMAC-SHA256 hashes with 600,000 rounds, never in readable form.
• Sessions. Sign-in cookies are HttpOnly, Secure and SameSite=Strict, and a session lasts at most 8 hours.
• Roles. Each person is an administrator, operator or viewer, and sees only the clients they're allowed to.
• Attempt limits. Password and code attempts are rate-limited, including for usernames that don't exist.
• Audit log. Sign-ins, changes and restores are recorded in each workspace's audit log.

Each client kept apart

Every client has its own workspace and its own storage. A workspace's accounts, servers and backups can't be reached from another workspace.

Signed software and updates

• The Windows agent and gateway are signed with Authenticode as DevSmooth Software Inc. Linux agent updates are signed with an Ed25519 release key.
• An agent checks the signature of an update before installing it, and rolls itself back if the new version fails to start.
• Updates never roll out on their own. You choose when, for one server, one client or all of them.

What we don't claim yet

MoorNest is in private evaluation. It doesn't hold SOC 2 or ISO 27001 certification, and it hasn't yet had an independent penetration test or cryptographic review. We won't show badges for any of these until they're done.

Reporting a vulnerability

If you think you've found a security problem in MoorNest or this website, email security@moornest.com. Tell us what you found, how to reproduce it and what you think the impact is. Please use test data only: never send real backups, keys or customer files. We'll reply, keep you updated while we fix it, and credit you if you'd like.

This website

The site sets no cookies, loads nothing from other servers and runs no analytics. What the waiting-list form collects is in the privacy notice.

Last updated 3 October 2026.