A service that holds standing access to thousands of tenants is the target attackers look for. 365 Rewind holds none: the work is done by an app on your computer, signed in as you. A hosted backup is stored encrypted, and the portal decrypts it on the server while it uses it: when it arrives, to count the changes and send change alerts; when a member opens, searches, compares or downloads it; for restore plans; and when a connected app fetches it. A backup kept in a local vault never reaches the portal.
Only people in your organization, through an app registration your organization owns.
The optional one-time setup creates the app registration in your own tenant. You see every line of it before anything is written, it asks only for the permissions the chosen workloads need, and you can remove it completely at any time. Every permission, by name.
We hold no password, token, client secret or certificate for any tenant, and there is no support account or back door. Nobody at 365 Rewind can read or change your tenant.
Unattended backups run as a Windows task on a computer you choose, with a certificate whose private key is kept by Windows on that computer and never leaves it.
Interactive sign-ins are held in memory by the app, never written to disk, never shown and never sent to the portal. They are discarded when you sign out or close the app.
Backups ask for read permissions only. A restore signs in on its own, asks only for what the chosen items need, and discards the sign-in afterward.
A restore prepared in the portal holds saved settings only. How they are applied is fixed in the app, and a restore script is one fixed file you can read, with your settings in it as data.
You choose per tenant, and can change it later.
If we do not hold it, it cannot leak from us.
Most of these rules are fixed in the app. Recreating risky items switched off is a default you can change for a restore.
The app reads the tenant and shows every change before anything is written, and writes nothing until you confirm.
Items that exist in the tenant but not in the backup are reported, never removed.
By default, a recreated Conditional Access policy returns in report-only mode, and mail flow rules, connectors and threat policy rules return disabled; you can choose to recreate them exactly as saved. Settings that are updated in place take effect at once.
The state before and after each item is kept in a journal on the computer that ran the restore, and the app offers to roll back every change it made from that journal. Microsoft can refuse an item, so a rollback can fail for some items, and it does not undo steps you carried out by hand.
An item that fails skips the items that depend on it, and the result says exactly which ones and why.
The app performs only operations described in its settings catalog. We sign the catalog with a key that is kept offline and is not on the portal server. The app verifies that signature with a key built into it before it uses the catalog, and checks every operation against fixed rules of its own. The portal delivers the catalog and cannot alter it.
No trackers, no analytics, no advertising, no third-party scripts or fonts.
Every page, this one included, may run only scripts and styles served by the portal itself, and cannot be framed by another site.
A sign-in to the portal lasts twelve hours at most. Roles decide who may change settings or prepare a restore: owner, operator or viewer.
Found a security problem? Write to security@glacierpointtech.com; how to report a vulnerability says what to send and what to expect.