Security and data handling
What Sigil asks for, what it stores, where it runs and how to report a problem. Written for the person who has to sign off admin consent.
Microsoft Graph permissions Sigil requests
Sigil requests three Microsoft Graph application permissions at admin consent. All three are read-only. No write permission and no mail permission is requested, so Sigil cannot send mail, change directory data or read message content.
| Scope | Type | Why Sigil needs it |
|---|---|---|
User.Read.All | Application | Reads the directory attributes a signature is personalised from: name, job title, department, phones, address, manager and extension attributes. The narrowest scope that returns title, department and phone numbers. |
Organization.Read.All | Application | Reads the organisation’s name and registered address once, at onboarding, to pre-fill the billing profile. It never overwrites an address an admin has saved. |
GroupMember.Read.All | Application | Resolves group membership for group-based assignment rules and group-based mailbox exclusions. |
Separately, the Outlook add-in’s manifest declares the Office permission ReadWriteItem. That is the add-in permission on the message currently being written, which the Office API requires in order to insert a signature into it. It is not a Graph permission and grants nothing on your tenant.
How sign-in works
- Users of the add-in are signed in silently with Microsoft Entra ID using nested app authentication; portal administrators sign in with a standard Entra single-page-app flow.
- Every API call carries an Entra-issued token that Sigil verifies itself: signature, issuer, audience, home tenant and scope. A separate
portal_adminscope keeps administrator tokens distinct from add-in tokens. - There are no shared secrets in the add-in. Its code is public by design; the security boundary is the verified token.
- No personal data travels in a URL. The add-in requests a signature with a POST whose body carries the mailbox address, so nothing identifying lands in a proxy log, browser history or referrer header.
Tenant isolation
Data is pooled with a tenant identifier on every row, and storage, cache and asset keys are tenant-scoped. The two code paths that legitimately query across that scope carry explicit guards with regression tests behind them, so isolation is checked rather than asserted.
Where data is stored and processed
Sigil runs on Cloudflare’s developer platform. The application and signature rendering run as Cloudflare Workers at the edge closest to the request, so a signature is rendered near the person composing the message.
- Database (tenant records, templates, rules, telemetry, audit log): Cloudflare D1, running in Cloudflare’s Western Europe region, with nightly backups to a bucket in the same region.
- Uploaded images (logos, banners): Cloudflare R2 object storage, located in Cloudflare’s Eastern North America region.
- Rendered-signature cache: Cloudflare KV, replicated globally so the next message a person writes is fast wherever they are. Entries are per tenant and are invalidated on publish.
No Cloudflare jurisdiction restriction (such as EU-only) is applied to these resources. If your organisation needs data kept within a specific jurisdiction, ask us before you onboard.
What we store and what we don’t
Stored
- Directory attributes, read on demand from Microsoft Graph to render a signature and cached only transiently.
- Signature templates, compliance footers, campaign banners and the images you upload.
- Signature activity metadata: which mailbox requested a signature, which template version was served, the compose type, and whether the add-in applied it. This is what the per-mailbox adoption report is built from.
- Click counts on tracked links in signatures and banners. Per-click detail expires after 90 days.
- Your organisation’s tenant record, subscription details and an append-only log of administrator actions.
Never stored
- Message content, and the rendered signature HTML.
- Recipient identities. Sigil does not know who you emailed.
- IP addresses of your users or of anyone who clicks a link.
- Payment card numbers. Card handling is performed by Stripe.
- Tokens. Telemetry stores metadata only.
Sub-processors
| Provider | Purpose | Location |
|---|---|---|
| Microsoft | Identity (Microsoft Entra ID) and directory data (Microsoft Graph) | Your tenant’s own Microsoft 365 region; Sigil reads through Graph and stores nothing there |
| Cloudflare | Application hosting, database, storage, caching and transactional email | Database, uploaded images and backups in Western Europe; cache and edge global |
| Stripe | Subscription billing and payment card processing | Stripe’s own infrastructure; card data never reaches Sigil |
GDPR, DPA and data subject requests
Your organisation is the controller of its directory data and Sigil is a processor. A data processing agreement can be read and accepted in the portal, and acceptance is recorded. Per-mailbox data subject access request export is built in. For our own account and billing records we act as controller; contact privacy@usesigil.app. The privacy policy has the full detail.
Reporting a vulnerability
If you believe you have found a security issue in Sigil, email security@usesigil.app. Please give us a reasonable time to investigate and fix the issue before disclosing it publicly. The same contact is published in /.well-known/security.txt.