Permissions Sigil requests

Sigil requests three Microsoft Graph application permissions at admin consent. All are read-only. No Graph write permission is requested anywhere, so Sigil cannot modify your directory even if it were asked to. The Outlook add-in has a separate, narrower permission of its own: it can read and write the message being composed, which is how the signature gets into it.

Permission	Used for
User.Read.All	Reading the directory attributes that personalise a signature
Organization.Read.All	Reading your organisation’s name, domain and registered address, and checking that consent is still in place
GroupMember.Read.All	Finding group mailboxes, assignment rules that match on Entra group membership, and the groups in cost management

Consent covers all three, or none of them

The consent screen is not a pick list. Sigil asks Microsoft for everything its application registration declares rather than naming permissions one at a time, so an administrator granting consent grants all three together and cannot approve two of them.

That is why the table above is short, and why it stays short. A permission added to the registration would widen what every consent screen after it asks for, so the list is treated as something to keep small rather than something to extend when a feature would find it convenient.

It also explains a difference you may see between two organisations. Consent records what was declared on the day it was granted, so an organisation that connected before GroupMember.Read.All was requested still holds the narrower grant, and keeps it until somebody consents again.

Why User.Read.All rather than something narrower

User.ReadBasic.All is the obvious narrower option, and it does not work.

It excludes jobTitle, department and the phone numbers, which are exactly the attributes a signature is made of. User.Read.All is the narrowest permission that returns them.

What is actually read

The attributes Sigil reads are the ones that can appear in a signature, plus what it needs to resolve the right mailbox:

Identity and contact details: display name, given name, surname, mail, business phones, mobile phone, fax number.

Role: job title, department, company name, employee id, employee type.

Location: street address, city, state, postal code, country, office location.

Manager: expanded explicitly, because Graph treats it as a navigation property rather than an attribute. Read on the compose path for the manager placeholders, and by attribute coverage so it can be scored.

On-premises extension attributes 1 to 15, which Graph only returns when explicitly selected.

Proxy addresses, used to verify that a sending alias genuinely belongs to the mailbox before it is printed into a signature.

Licence and account state, including how each account was created, used to count billable seats and to exclude disabled accounts and accounts invited in from outside your organisation. The same reading is what tells you whether excluding a given mailbox would save anything, in cost management.

The profile photo, but only for organisations whose template contains a Photo block. User.Read.All already covers it, so adding one needs no new consent. See per-user images.

These are the same attributes every colleague can already see in the address book. What Sigil adds is that they can only be read with a valid, verified Entra token.

Organization.Read.All

Sigil reads your organisation’s record to name your tenant and to pre-fill the billing profile from your registered address. It reads it again when your billing details are set up or refreshed, and at sign-in only if your tenant has no name or no billing profile on record yet. It is also the quick check that Sigil can still reach your directory. That check runs when the Getting started page loads (a successful answer is remembered for five minutes, so a lapse shows within that window), when Tophhie Cloud support looks at your organisation’s health, and in the nightly seat count if reading your directory fails, to tell a withdrawn consent apart from a passing fault.

None of this is on the signature path. Composing a message never reads it.

GroupMember.Read.All

Four things use it.

Group mailboxes. When somebody sends as a Microsoft 365 group, a distribution list or a mail-enabled security group, the From address belongs to a group rather than a person. Sigil only looks under groups after the address has failed to match a user, so ordinary mail never reaches this step. See group mailboxes.

Assignment rules that match on Entra group membership read the groups a person belongs to. Rules that match on directory attributes do not touch it.

Cost management reads the membership of a group you have excluded, and searches your groups for the picker. It also lists your mail-enabled groups, so a group’s address on your list is recognised as a group mailbox rather than flagged as missing from the directory.

The mailbox search in the portal’s preview, simulator, download and test email boxes also lists matching mail-enabled groups, so a group mailbox can be previewed. For an organisation that consented before this permission was requested, the search simply shows people only.

It is requested at consent time regardless, because asking for it later would mean a second consent round trip at the moment an administrator is trying to write a rule or exclude a group.

One permission covers both directions, which groups a person belongs to and who belongs to a given group, so neither feature asks for anything the other did not already need. An organisation that consented before this permission was requested will find both of them report the problem rather than fail silently. Group mailboxes behave as they did before the lookup existed: a message sent as one is refused as an address Sigil cannot find.

Application permissions, not delegated

The Graph reads happen with an app-only token, per tenant. That is what allows a signature to be rendered for a shared mailbox, a group’s mailbox or an alias, where there is no signed-in user to borrow permissions from.

The app-only token reads your tenant’s directory and nothing else. There is no cross-tenant read path: an address outside your organisation simply does not resolve.

No domain allow-list

Sigil deliberately has no configured list of permitted email domains. A list would add nothing, because the app-only token is already scoped to one directory, and it would break every user whose address is not on the listed domain. Many organisations span several domains.

Two delegated scopes

Alongside the Graph permissions, Sigil’s own API exposes two delegated scopes:

Scope	Used by
access_as_user	The Outlook add-in
portal_admin	The admin portal, the designer, and the page where colleagues fill in their own details

The presence of portal_admin in a token is what tells a browser sign-in from an add-in one, so an add-in token can never reach an admin endpoint.

The name is narrower than the scope is. Anybody signing in through a browser gets it, including a colleague who holds no role and only ever opens their own profile page. That is deliberate: minting a second scope for the profile portal would put every organisation that has already consented through a fresh consent round for no security gain, because what a token can actually reach comes from the roles held in Sigil rather than from the scope. A token with no role behind it reaches that person’s own details and nothing else.

Reviewing what was granted

In the Microsoft 365 admin centre or the Entra portal, look under Enterprise applications for Sigil. The Permissions tab lists exactly what was consented to and when.

1. In the Entra portal, open Enterprise applications.
2. Open Sigil.
3. Open the Permissions tab and read the list. An organisation that consented before GroupMember.Read.All was requested will not see it here until somebody consents again.

Consent can be withdrawn there at any time. Withdrawing it stops Sigil reading your directory, which stops signatures rendering.