Security & trust

Security at a glance

• Read-only, always. The only Azure role TenantThrift ever holds is built-in Reader. It cannot change, create, start, stop or delete anything.
• Least privilege. One delegated Microsoft Graph permission (User.Read) for sign-in, and Reader RBAC on the subscriptions you pick. No application permissions, no directory read, no data-plane access.
• Read-only, revocable identity. The identity that reads your Azure is a non-exportable certificate in Azure Key Vault, and it holds only built-in Reader — it cannot change, start, stop or delete anything, and you can revoke it instantly from your side.
• Your kill switch. Delete the enterprise app or remove the Reader assignment and access ends instantly — on your side, no ticket.
• Tenant isolation. Every record is scoped to your organization and enforced with database row-level security.
• EU data residency. Database, storage and processing in Frankfurt; an independent Swiss product, handled under the GDPR and Swiss revDSG.

What happens, step by step

The complete path from sign-up to first scan — every point where TenantThrift touches your tenant, and what it touches.

1. Create an account. Sign up with a work email — no credit card. This creates your organization in TenantThrift. Nothing touches Azure yet.
2. Connect a tenant (admin consent). You click Connect with Microsoft. A tenant admin approves a one-time admin consent for our multi-tenant application, and Azure creates a service principal — an “enterprise app” — in your tenant that represents TenantThrift. The only permission requested is Microsoft Graph delegated User.Read, the minimum for sign-in to exist. No application permissions, no directory read, and no secret is generated by or collected from you.
3. Grant Reader. You assign the built-in Reader role to that service principal on the subscriptions — or a management group — you choose, with one az command or in the portal. This, and only this, is what a scan uses.
4. Verify. The app confirms access and lists exactly the subscriptions it can now read. You see the scope before anything runs.
5. First scan. A background worker requests a short-lived access token for your tenant and reads, in memory: resource metadata (Azure Resource Manager), cost data (Cost Management) and, for VMs, runtime metrics (Azure Monitor). It computes findings and bounded cost aggregates and persists only those. The tenant token lives about an hour in worker memory and is never written down.
6. Ongoing. Scans run on your schedule. Nothing about this widens access — it stays Reader, and you can revoke at any time.

What you grant — least privilege

• Microsoft Graph — delegated User.Read. The minimum required for the consent and sign-in to work. We never read your directory, users or groups.
• Azure RBAC — built-in Reader on the subscriptions you pick. This is the entire footprint a scan uses.
• Explicitly excluded: no write, Owner or custom role; no Key Vault access; no data-plane access to storage accounts, databases or key material; no ability to change, create, start, stop or delete anything. Every fix TenantThrift surfaces is guidance — the exact command shown for you to run yourself.

How TenantThrift authenticates to Azure

This is the “what if you get breached” answer — the one most cost tools gloss over.

• TenantThrift is a confidential-client application. To act as itself against Microsoft’s identity platform, it must prove its identity with a credential.
• That credential is a certificate whose private key is generated inside Azure Key Vault and marked non-exportable. The key never leaves Key Vault — not to our servers, not to disk, not to us.
• Every token request is signed by calling Key Vault’s signing operation (RS256). The application only ever handles the resulting signature, never the private key.
• The worker reaches Key Vault through an Azure Managed Identity — itself not a copyable secret — scoped to only the signing and certificate-read operations it needs. The identity that reads your Azure uses this certificate, not a client secret.
• Sign-in (“Continue with Microsoft”) uses a separate OAuth client secret, held only in our authentication provider. Whatever the credential, the ceiling on any access to your tenant is built-in Reader — read-only, and revocable by you in one click.
• Net effect: the most any TenantThrift credential can ever do against your tenant is read it — no write, no ability to change, start, stop or delete anything — and you can revoke that access instantly from your side. We never receive or store your Azure credentials, and tenant access tokens live only in worker memory, about an hour.
• When the certificate is rotated, superseded versions are disabled so only the current one is ever trusted.

Data, encryption & isolation

• What we store: bounded findings and cost aggregates, your connection settings, account and billing identifiers, and one PDF per scan. The complete, table-by-table list is in the docs.
• What we never store: credentials of any kind, metric time series, log content, network data, or a full resource inventory. Tenant tokens exist only in worker memory, for about an hour.
• Encryption: everything is encrypted in transit (TLS) and at rest. On top of that disk-level encryption, the fields that describe your estate are sealed one by one before they ever reach the database, under a key belonging to your organization alone (AES‑256‑GCM; that key is itself wrapped by an RSA key in Azure Key Vault and is never stored beside the data it protects). Sealed this way: resource IDs and resource names, the guidance and cost breakdowns derived from them, tenant display names, report recipients — email addresses and Slack/Teams webhook URLs — and the addresses in the audit log. A copy of the database without Key Vault access is ciphertext for all of it.
• What is deliberately readable: your sign‑in address, because we need it to sign you in; your organization’s name; Azure tenant and subscription GUIDs, which identify a customer but open nothing; and our own vocabulary — finding titles, severities, per‑SKU licence counts. We would rather name these than claim more than we do.
• Isolation: every row is scoped to your organization and enforced with database row-level security. Report PDFs live in a private bucket and are served only through short-lived signed URLs after an access check.

Hosting & data residency

• Database, object storage and scan processing run on EU infrastructure in Frankfurt.
• TenantThrift is an independent Swiss product; data is handled under the EU GDPR and Swiss data-protection law (revDSG).
• Payment is handled by Stripe; we store only customer and subscription identifiers, never card details.
• The full sub-processor list is in the DPA.

Your controls

• Revoke anytime. Delete the TenantThrift enterprise app in your tenant, or remove the Reader assignment — access ends immediately.
• Delete a connection. Removes its scans, findings and stored reports right away.
• Delete the organization. Removes every connection, all derived data and your account.
• Team roles. Admin, Editor and Reader keep access inside your own org least-privilege too.

Reporting a security issue

Found something, or want to run a review before you connect? Email info@simonvedder.com — it reaches me directly. Security is my day job; I’ll take it seriously and respond fast. For the contract and processing terms, see the Terms, Privacy Policy and DPA.