Security Model

Watchmont manages other organisations' Microsoft 365 estates, so it is built to be judged on security. This page explains, honestly and specifically, how the platform protects your data and your clients' data.

Where your data lives

• Every MSP runs on a dedicated instance: its own databases, its own APIs, its own secrets store and its own subdomain. Client data is never pooled with another MSP's.
• All infrastructure runs in AWS London (eu-west-2). Data does not leave the UK region.
• Deleting an instance deletes everything: databases, secrets and configuration are removed together, with nothing shared to clean up afterwards.

Encryption

• Every database table is encrypted at rest with AWS KMS.
• All storage is encrypted at rest; all traffic is TLS 1.2 or higher with HSTS enforced.

Credentials and secrets

• The app credentials Watchmont uses to reach a customer tenant are stored in AWS Secrets Manager, in a namespace scoped to your instance. They are never stored in the database and never sent to a browser.
• Access to an instance's secrets is enforced with per-instance IAM policy: one instance cannot read another's.

Signing in

• Staff sign in with Microsoft single sign-on only. There are no Watchmont passwords to phish, reuse or leak.
• Each instance is pinned to your Entra tenant: accounts from any other directory are rejected even after a successful Microsoft login.
• Sessions are short-lived signed tokens with CSRF protection. Roles live inside the token, so a role change takes effect at next sign-in.
• Optional IP allowlisting restricts the whole portal to your office and VPN addresses, enforced both at the network edge and again at the API layer.

Staff access control

Three independent controls apply to every staff member:

1. Role (SuperAdmin > Admin > Engineer > User) controls what they can do.
2. Client scope controls which clients they can see and act on.
3. Page grants control which portal areas they can open.

A write action succeeds only when the role allows it and the target tenant is provisioned read/write. See Roles & Access.

Least privilege into customer tenants

• Tenants onboard read-only by default. Read/write is a deliberate, per-client upgrade.
• The permission set is fully documented: see App Permissions for every scope and what it powers. You can hand that page to a customer asking "what does this app have access to?".
• New features that need new permissions never get them silently. The tenant shows RE-AUTH NEEDED and a customer Global Admin must consent again before anything changes.
• Customers can revoke access at any time by removing the app from their tenant.

Audit and accountability

• Staff actions are recorded in the audit log (Admin › Settings › Audit Log).
• Scheduled report delivery keeps a send history, success and failure per report.
• Background sync, alerting and report jobs run as scheduled tasks that a SuperAdmin can see and control from the portal.

Application hardening

• Strict Content Security Policy and a full set of security response headers on the portal.
• Quarantined email previews render inside a fully sandboxed frame, so attacker-controlled message content can never run script in the portal.
• The portal's APIs only accept traffic that arrives through the platform's own edge, carrying the expected origin proof.

What Watchmont deliberately does not do

• Customers never log in. There are no customer accounts to compromise. Clients receive reports; only your staff touch the portal.
• No standing user credentials. Access to customer tenants uses app-only tokens minted on demand, not a signed-in admin session that could be replayed.
• No silent scope growth. Permissions only expand through explicit customer re-consent.