How Rollout protects your data
Rollout works with personal data of your clients' employees and has read access to their Microsoft 365. That's why security isn't one lock but a series of layers that each work on their own. This page explains them and shows how to demonstrate them.
Who talks to whom
Scroll here or press play.
The layers
| Layer | What it does | How you see it |
|---|---|---|
| Sign-in at Microsoft | MFA and Conditional Access of your own tenant; only assigned engineers | Entra → Enterprise applications |
| Row Level Security | Every table; an organization never sees another's data | Security page: "tables without RLS: none" |
| Roles in the database | Administrator, engineer, read-only, enforced in the database itself | Team page |
| Server gateway | Public functions only via your server | /api/ready: "gateway": "ok" |
| Revoking sessions | Immediate, even with a valid token; also sessions outside the app | Security center → Sessions |
| Read-only at clients | Rollout can't change anything, unless you deliberately turn on one-click fix | Connection test: permissions per client |
| No keys to client tenants | Federation: Microsoft only trusts your Vercel project | Entra: only a federated credential |
| Two locks per tenant | Allowlist outside the app and a client of your organization | GRAPH_ALLOWED_TENANTS |
| Public links | 256 bits, only the hash stored, expiry date, revocable | Revocable per project |
| Tamper-evident audit log | Hash chain: every change, provably untouched | Security page → verify chain |
| Web security | Strict CSP with nonce, HSTS, no framing, no referrer | Response headers |
What Rollout stores
Only work data: name, UPN, email, department, job title and location, plus laptop serial number and appointment. No passwords, no national ID numbers, no private data. Responses from Microsoft aren't stored, only the outcome per check (for example "license: ok").
Demonstrating it
- Security page
In Rollout: Security. Everything the server and the database know about themselves, in green, orange or red. Download the report (JSON) for your records.
- Store the head hash
The same page shows the head hash of the audit log. Store it regularly outside Rollout, for example in your password vault. That way you can later prove nothing was changed, not even by someone with access to the database.
- Every version tested
Every code change runs through CI: unit tests, SQL tests on the security rules, a scan for leaked secrets across the whole history,
npm auditand a software bill of materials (SBOM). The commit is shown on the Security page. - Independent pen test
Have an independent party test a test installation once. Because every installation runs the same code, the outcome applies to all of them.
Reporting a vulnerability
Think you've found a vulnerability? Do not report it in a public issue; email security@rollout365.com with a description, the steps to reproduce and any evidence. You'll get a response within two business days. Don't look at other people's data, don't cause an outage and don't make anything public before it's fixed.