Continuous monitoring

Outlook Org Integration

Monitor every Microsoft 365 mailbox in your tenant through the Graph API — no per-user add-in installs. One setup pulls your directory, assigns seats, and analyzes incoming mail for phishing within seconds of arrival.

Set up in IntegrationsOpen Monitoring Hub
SOC 2 Type 1 attested · Type 2 in progress

A Microsoft 365 administrator is required

Setup involves privileged actions in your own Microsoft consoles: an Entra ID administrator registers the app and grants admin consent, and — recommended, not required — an Exchange administrator runs a short PowerShell script to narrow which mailboxes the credential can reach. A Blue Lantern account admin can start the wizard and hand those steps to the right people; every value they need is shown copy-ready.

Whole-tenant coverage

An app registration you own, with permissions you consent to, reads mailboxes directly through Microsoft Graph — every user is covered with nothing to install.

Real-time analysis

Graph change notifications push new mail to us as it lands; suspicious messages are analyzed within seconds and appear in the Monitoring Hub with a verdict. Subscriptions are created and renewed automatically — nothing for you to configure.

Seats assigned automatically

Members of your monitored group are seated up to your purchased seat count; the rest join unmonitored until you add seats. Ingestion is seat-only.

How setup works

Our guided wizard presents each Microsoft-side step with copy-ready values, then validates the connection live before storing anything.

  1. 1

    Start the wizard in our UI

    Open Account → Integrations (or the button above), click Add Integration, and choose Microsoft 365 / Outlook. The first step asks one decision up front: whether to allow the optional auto-quarantine action, which adds a write permission.

  2. 2

    Entra ID: register an app and consent

    Register a single-tenant app, add these application permissions (not delegated), and grant admin consent:

    • Mail.Read
    • User.Read.All (directory)
    • GroupMember.Read.All (resolve the monitored group)
    • Mail.ReadWrite (only for auto-quarantine)
    • AuditLog.Read.All (only for the optional MFA and dormancy checks; dormancy also needs an Entra ID P1/P2 license)
    • MailboxSettings.Read (only for the optional auto-forwarding and inbox-rule checks)
    • Application.Read.All (only for the optional AI exposure scan)

    Then set Assignment required? → No in Enterprise applications → Properties. Microsoft only signs the change notifications we require when this is set; otherwise it delivers a null token and every notification is rejected. If tenant policy forbids it, assign the Graph Change Tracking service principal a role on the app instead:

    0bf30f3b-4a52-48df-9a82-234910c4a086

  3. 3

    Create a credential

    A certificate is preferred — we read its expiry directly and warn you before it lapses. A client secret works too, but you must supply its expiry date, and Entra caps secrets at 24 months (often less by tenant policy). Commands are below.

    An expired credential silently stops monitoring. We track the date and surface a warning on the Integrations page well before it matters.

  4. 4

    Scope the mailboxes (recommended)

    Create a mail-enabled security group of the mailboxes to monitor and apply an Application Access Policy restricting the app to it. The wizard generates this PowerShell with your real values. It is recommended rather than required — you can connect without it after an explicit acknowledgement, which we record.

    The group is required either way: it defines who we analyze and seat. The policy narrows what the credential itself can reach.

  5. 5

    Connect and verify

    Enter the tenant id, app id, credential and group. We authenticate to Graph, confirm consent, and check the scope by proving an in-group mailbox is readable and an out-of-group one is not. If the proof does not pass, your configuration is saved as pending — nothing needs re-entering — and you can verify later without redoing the form. Once it passes, your directory is pulled, seats are assigned, and subscriptions are armed automatically.

Commands you will need

The wizard shows these with your values substituted. They are here so an admin can prepare ahead, or hand the Exchange step to someone else.

Create a certificate (OpenSSL, any platform)

Upload the resulting bluelantern-cert.pem to Entra (Certificates & secrets), and give the wizard both halves. -nodes means no passphrase — a protected key cannot be used unattended and will fail at connect. RSA 2048–4096 only.

openssl req -x509 -newkey rsa:2048 -nodes -days 730 \
  -keyout bluelantern-key.pem -out bluelantern-cert.pem \
  -subj "/CN=BlueLantern Mail Monitoring"

Create a certificate (PowerShell, Windows)

Exports a .cer for Entra and a .pfx you extract the private key from.

$cert = New-SelfSignedCertificate -Subject "CN=BlueLantern Mail Monitoring" `
  -CertStoreLocation "Cert:\CurrentUser\My" -KeySpec Signature `
  -KeyExportPolicy Exportable -KeyLength 2048 -NotAfter (Get-Date).AddYears(2)
Export-Certificate -Cert $cert -FilePath .\bluelantern-cert.cer
$pwd = ConvertTo-SecureString -String "<temp-password>" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath .\bluelantern.pfx -Password $pwd

Extract the private key from the .pfx

The .pfx is not directly usable — the private key must reach us as PEM. Delete the .pfx and its password afterwards.

openssl pkcs12 -in bluelantern.pfx -nocerts -nodes -out bluelantern-key.pem

Restrict which mailboxes the app can read (Exchange Online PowerShell)

Recommended. Replace the placeholders with your admin UPN, app id, domain, and the mailboxes to monitor. Exchange can take 30–60 minutes to enforce a new policy, so a connect attempt right after this may need one retry.

Connect-ExchangeOnline -UserPrincipalName <ADMIN_UPN>

# 1. The mailboxes Blue Lantern is allowed to read.
New-DistributionGroup -Name "BlueLantern-Monitored" `
  -Alias BlueLantern-Monitored -Type Security `
  -Members @("user1@<DOMAIN>","user2@<DOMAIN>")

# 2. Restrict the app to exactly that group.
New-ApplicationAccessPolicy -AppId <CLIENT_ID> `
  -PolicyScopeGroupId BlueLantern-Monitored@<DOMAIN> `
  -AccessRight RestrictAccess `
  -Description "Restrict Blue Lantern to monitored mailboxes"

# 3. Verify: in-scope must be Granted, out-of-scope must be Denied.
Test-ApplicationAccessPolicy -Identity user1@<DOMAIN> -AppId <CLIENT_ID>
Test-ApplicationAccessPolicy -Identity <OUT_OF_SCOPE_MAILBOX> -AppId <CLIENT_ID>

Optional: daily AI exposure scan

Which AI tools can touch your tenant's data — the inventory insurers and customers have started asking for. Enable it with one checkbox in the integration's Settings.

How it works

Once a day we enumerate the third-party apps in your tenant through Graph — every service principal, delegated OAuth grant, and application-permission assignment — and classify each grant: whether the app is a known AI tool (a curated catalog plus name heuristics), how far its scopes reach (mail, files, and calendars versus sign-in only), whether the grant is a single user's or org-wide admin consent, and whether the publisher is verified. Unverified apps holding data scopes are flagged too — the classic OAuth-phishing shape, AI or not.

Where results land

Each scan is an AI Exposure run in the Monitoring Hub with per-app check rows and an exportable report. The first scan records a baseline; after that, newly appearing risky apps lead the report and can trigger alert rules on the AI Exposure run type. An AI exposure section also appears in the attestation report.

Requires the Application.Read.All application permission with admin consent (step 2 above). If it was not granted at connect time, grant it and re-run the connect flow. The scan reads grant metadata only — app identities and scope strings, never message or file content — and mail monitoring continues unaffected either way.

Sensitive actions, and how exposure is limited

This integration reads mailboxes across your tenant. What you are granting, and the corresponding controls:

  • Application permissions are tenant-wide by default

    Unlike delegated access, Graph application permissions reach every mailbox in the tenant unless an Application Access Policy narrows them. We check whether one is enforced and record the outcome — verified, unproven, or knowingly accepted (stored with who acknowledged it and when). Independently of Exchange, our ingest worker refuses any mailbox without a seat, so the set of mail we actually analyze is bounded by your seat assignments either way.

  • Credential custody

    The certificate private key (or client secret) is transmitted once over TLS and stored in AWS Secrets Manager — never in our database, and never returned by any API. Deleting the credential in Entra, or removing the app registration, revokes our access immediately and entirely from your side.

  • What we read, keep, and write

    Permissions are read-only unless you enable auto-quarantine, which adds one write scope used solely to move a flagged message to Junk Email — never to delete or send. Raw message payloads auto-delete within 24 hours and analysis reports within 90 days. Change notifications carry no mail content, and every one is verified as Microsoft-signed and bound to your tenant before we act on it.

Seats and billing

Requires an active seat plan. Members of your monitored group are seated up to your purchased count and unseated mailboxes are not ingested; if the sync reports unmonitored users, add seats and re-sync. See pricing.