Cindera · Security & Privacy

Security & Privacy

Cindera is a security product, so the way Cindera itself handles your data has to stand up to scrutiny. This page is the technical reference IT and legal teams use to clear Cindera for production.

What Cindera reads from your tenant

Cindera uses a dedicated Microsoft Entra ID application registration (the "scanner" app) with read-only Microsoft Graph permissions, granted once via admin consent. Every permission below is read-only and exists because at least one rule needs it.

User.Read.All: Enumerate user accounts, identify guests, and detect dormant accounts. Needed by the admin MFA, dormant privileged, and guest account rules.
UserAuthenticationMethod.Read.All: Inspect which authentication factors each user has registered (e.g. Authenticator app, FIDO2 key). Used by the MFA registration coverage rule. The secrets themselves are never returned by Graph.
Policy.Read.All: Read conditional access policies and authentication strength policies to detect missing legacy auth blocks, report-only policies, and gaps in enforced MFA.
Application.Read.All: Enumerate registered applications, service principals, app role assignments, and client secrets. Drives the risky app consent, overprivileged service principal, expiring secret, and owner-less app rules.
Directory.Read.All: General directory metadata (tenant details, group context for role analysis). Required by Microsoft for several of the rules above to return complete results.
RoleManagement.Read.Directory: Read directory role definitions and active assignments, including PIM-eligible vs permanent assignments. Used by the excessive Global Admin, permanent privileged assignment, and break-glass rules.
AuditLog.Read.All: Read sign-in activity to detect dormant privileged accounts. Cindera reads activity timestamps only — never the contents of any sign-in event.

What Cindera NEVER reads

Cindera does not request, and the scanner app cannot access, any of the following:

Mailbox content. No mail items, attachments, or folder structures. The scanner has no Mail.* permission.
Files. No OneDrive, SharePoint document content, or file metadata. No Files.* or Sites.* permission.
Calendar and contacts. No appointments, meeting invites, or contact lists. No Calendars.* or Contacts.* permission.
Teams chats and channel messages. No Chat.* or ChannelMessage.* permission.
Passwords or credential material. Microsoft Graph does not expose these to any third party, and Cindera does not attempt to read them.
End-user productivity data. Activity reports, usage analytics, and similar telemetry are out of scope.

Where your data is stored

Cindera is operated in the European Union. The sub-processors that handle customer data are configured to keep data in EU regions wherever the service supports it.

Database: Supabase PostgreSQL · EU region (Frankfurt). Stores scan results, findings, tasks, audit logs, and account data.
Application hosting: Vercel · EU region (Frankfurt). Edge telemetry may transit US infrastructure under Standard Contractual Clauses.
Rate-limit Redis: Upstash · EU region. Holds counter keys keyed by tenant or IP only — never scan content or PII.
Background jobs: Inngest. See the sub-processor list for current regions. Covered by SCCs where applicable.
Transactional email: Resend · US. Used for sign-in links, critical-finding alerts, and recurring report delivery. Covered by SCCs.

The full and current list lives at cinder.example/subprocessors.

How we handle access tokens

Microsoft Graph access tokens for the scanner are never persisted. Each scan requests a fresh token using the client-credentials flow, holds it in memory for the duration of the scan, and discards it once the run finishes. The scanner application's client secret itself is held in the server's environment variables — never logged, never written to the database, never returned in an API response.

Why this matters

If Cindera's database is ever compromised, an attacker still has no way to call Microsoft Graph against your tenant — the tokens to do so don't exist there. They'd need the scanner client secret, which lives only in the runtime environment.

Session security

The Cindera console enforces tight session limits because it is a security and compliance tool:

Absolute cap. A single session is valid for at most 8 hours from sign-in. After 8 hours, re-authentication is required regardless of activity.
Idle cap.If you don't interact with the app for 1 hour, your session is invalidated and you are signed out on the next request.
Cookies. Auth cookies are HTTP-only, Secure, and SameSite-Lax. CSRF and state cookies are used during the sign-in and admin-consent flows.
Transport. All traffic is served over TLS with HSTS (2 years, preload). The app sets a strict Content Security Policy, frame-ancestors deny, and X-Content-Type-Options nosniff.

Audit logging

Every write operation inside the Cindera console — finding status changes, task creation, report deliveries, consent grants and revocations — is recorded in a tamper-evident audit log in the same database transaction as the change itself. If the audit log write fails, the change is rolled back.

Audit log entries include the actor (user ID), the action, the target resource type and ID, a timestamp, and a structured metadata payload. They are tenant-scoped and retained for 7 years for accountability and audit evidence.

Disconnecting Cindera

You can disconnect Cindera from your Microsoft 365 tenant at any time. There are two layers — both are useful depending on what you want to achieve:

1. Disconnect in Cindera

Open Connections and click Disconnect. This marks the EntraConnection as consent_revoked, stops all scheduled and on-demand scans, and freezes the historical data so you can keep referring to it. Scan data is purged 30 days after disconnect unless you request earlier deletion.

2. Revoke in the Entra admin centre

For full revocation, an admin in your tenant should also remove Cindera's consent from Enterprise applications in the Entra admin centre. Find the Cindera scanner application and click Properties → Delete. This removes the service principal from your tenant entirely, so no further Graph calls are possible even if Cindera's scanner secret were mishandled.

Tip

Step 1 alone is enough to stop Cindera reading data. Step 2 is the belt-and-braces option for organisations with strict offboarding policies.

Sub-processors

A current list of sub-processors, including region, purpose, and transfer mechanism, is published at cinder.example/subprocessors. We update that page when sub-processors change and publish material additions before they go live.

Data retention

Scan results & findings: Retained for the duration of the subscription. Purged 30 days after disconnect unless you request earlier deletion.
Audit logs: 7 years from creation. Retained for security, accountability, and audit evidence.
Account data: While the account is active, plus 90 days after closure for incident-investigation purposes, then deleted.
Public NIS2 assessment leads: 24 months from submission.
Microsoft Graph access tokens: Never persisted. Held in memory for the duration of a single scan and discarded immediately after.

For full detail on legal bases and your data-subject rights, see our Privacy Policy.