Immutable*
Immutable, until an account holding the bypass permission says otherwise.
EnterProtect's locks use compliance mode, which has no bypass, so nobody can shorten one, including us.
EnterProtect keeps every client's cloud backup in the region you choose, under compliance-mode locks that renew daily and can only be extended, and backs each claim on this page with evidence you can forward to an auditor.
An insurer asks how recovery is proven. A regulator asks where the data sits. A questionnaire asks who can delete a backup. A vendor's assurance isn't something you can forward, so here's the fine print behind most backup, and the evidence that replaces it.
Immutable, until an account holding the bypass permission says otherwise.
EnterProtect's locks use compliance mode, which has no bypass, so nobody can shorten one, including us.
Gone, says the vendor, with nothing to hand the client.
EnterProtect ends every destruction with a signed certificate that outlives the data it describes.
A vendor engineer who can read your clients' backups whenever they like.
Here support reaches nothing until your Owner approves one resource, for a window that ends by itself.
A missed invoice that turns into lost backups.
Here a missed payment stops new captures, and everything already accepted stays locked and recoverable.
Every cloud recovery point sits under a 30-day compliance-mode object lock that renews daily for as long as it's retained. Retention can be extended, never shortened, by anyone, including EnterProtect. A missed renewal is an incident.
An accepted cloud recovery point stays recoverable and unaltered when any one of these is compromised. Each case is a release test, not a promise summed up as hack-proof.
The agent can open a session and upload. It can't list, read, delete, shorten or decrypt anything. Ransomware running as SYSTEM can stop future backups, which raises an alert, and can't reach back into history.
The appliance is a cache for speed, and root can destroy that cache. Its cloud credential can only add data, for one client, and is revoked from the console without the appliance's help. The cost is recovery time, not data.
Retention policies, holds and the recycle bin all live inside the tenant. The backup lives outside it, where a compromised Global Administrator can't reach.
Retention, encryption keys and the audit record run as separate services, with separate credentials and separate administration. The console requests. It never decides.
It can't shorten retention already committed to a recovery point, delete one, destroy a key or rewrite the audit trail. A shorter retention setting applies only to recovery points created after it.
The ingest credential can only add data. None of them can delete an accepted object, shorten its lock or administer the storage account.
EnterProtect support reaches nothing by default. Access is a lease your Owner approves, for one resource, and it ends by itself.
An engineer requests access tied to a support case, naming one resource and what they need to do. A request nobody has approved reaches nothing at all.
Reading backup content needs a second EnterProtect approver who is never the requester. Operational metadata needs your approval only.
Nobody at EnterProtect can approve their own access. The lease reaches the one resource it names and nothing beside it.
Your console shows the lease counting down. It expires by a database rule, so access ends on time even if nothing runs, and you can revoke it sooner.
Every grant and every use lands in your client's own access record, with its case, scope and expiry. You're notified when a grant is approved and again when it ends.
Each claim below is a control in the product rather than a line in a policy, and each leaves a record you can point to.
Microsoft 365 is captured by a read-only identity that writes nothing, and write access exists only for one restore, scoped to it, and expires by itself. A protected machine's agent can upload and nothing else, and can never decrypt what it sent.
You choose each client's storage location from the set you allow, and the region is confirmed before the first capture. Backups are stored there, and moving storage is an explicit, audited migration.
Content is encrypted before or at ingest in its region and never lands in storage as plaintext. Keys sit with a key authority outside the console, and no console, storage or MSP administrator can destroy one to delete data early.
Audit rows are insert-only for everyone, your Owner and EnterProtect included. Browsing a recovery point is recorded as content access, and people are deactivated rather than deleted, so the record outlives their access.
When a client's service ends, eligible data is destroyed within 31 days unless a hold keeps it, and a signed certificate records what was destroyed, where and when. An incomplete purge gets no certificate.
An insurer asks for evidence of tested backups, and pulling it together by hand takes a day per client that nobody pays you for. EnterProtect builds it in a minute.
One dated document per client, covering every product they use: validation results, restore-test outcomes, immutability receipts and destruction certificates, each traceable to the record it came from. Anything it can't show is named, and no section can be left out, so a missing section never hides a gap.
File Backup runs on an open-source file engine, embedded behind EnterProtect's own adapter. The engine handles the file mechanics. Everything that's a promise stays EnterProtect's: what counts as a recovery point, who may delete one, the keys, retention and audit. For every version we ship, we keep the exact source, build toolchain, dependencies, patches, licences and SBOM. The repository format is documented as a specification, the engine version is recorded on every recovery point, and a clean-room recovery with no console, no database, no network and no upstream project is exercised on a schedule. Open source never means security is outsourced: when upstream is slow on a CVE, we patch it ourselves.
Something we haven't answered? A person reads every message.
Not an accepted cloud copy. Locks are in compliance mode, which has no bypass, and retention, keys and audit run outside the console's reach. An attacker who fully compromises the console, or your Owner account, can't shorten retention or delete a recovery point.
No. A compliance-mode lock can be extended and never shortened, by anyone, including EnterProtect. EnterProtect's own staff tools can request, schedule and record, and they never destroy.
Not unless your MSP Owner approves it. Support holds nothing by default. A grant names one resource and a window, backup content also needs a second EnterProtect approver who is never the requester, and every grant and every use lands in the client's own access record. If that record shows no lease, EnterProtect can't see in.
In the storage location you choose for each client, from the set you allow. The region is confirmed before the first capture, and moving storage is an explicit, audited migration.
No, and the product says so. The appliance is a local cache for speed, encrypted and integrity-checked, and its root account can destroy it. The immutable copy is in EnterProtect's cloud, on by default, and turning it off needs a recorded acknowledgement that nothing is then immutable.
New captures stop after a short grace period, and you're told out of band. Everything already accepted stays immutable and recoverable for its full term, and a suspended MSP can still get a recovery through support. Non-payment can never authorise early deletion.
With a signed destruction certificate. When service ends, a 30-day cooling-off runs alongside the last lock, and eligible data is destroyed within 31 days unless a hold keeps it. The certificate names the client, products, storage locations, timeline, authorisation and completion time, and it's issued only once the inventory reconciles.
Yes, under per-client keys or finer, before or at ingest in its region, so nothing lands in storage as plaintext. The identity that sends a backup can never decrypt it. Decryption for a restore activates just in time and expires with that restore.
For BCDR, yes. An appliance keeps backing up, validating and serving restores from its last signed configuration while EnterProtect is unreachable. With the offline recovery key your Owner generates and keeps, an exact recovery point on an appliance or a portable bundle restores read-only with no EnterProtect service running. EnterProtect stores only the public half of that key.
No, never, for any reason, including during setup. Microsoft 365 connects through Microsoft's admin consent flow, and the client's administrator sees the exact list of permissions requested before consenting.
Assurance isn't evidence. Here's what EnterProtect puts in writing about your clients' backups.