Security & trust

Security built into the platform,
not bolted on.

Beacon reaches your clients' Azure tenants through a read-only, least-privilege app registration. Stored secrets are encrypted with AES-256-GCM, every administrative action lands in a tamper-evident audit log, and each tenant's credentials stay isolated from every other. Here is exactly how each control works.

Credential security

Beacon never asks for admin credentials, and never needs them. The platform connects through a read-only app registration that limits what Beacon can see to exactly what compliance scanning requires. The client secret you provide is encrypted before it ever touches disk.

Least-privilege app registration
You grant Beacon a service principal with Graph and Azure Resource Manager Reader roles only. No write, Contributor, or Owner permission is ever requested, so Beacon can read posture but cannot change a single setting in your tenant.
AES-256-GCM encryption at rest
Each app registration secret is sealed with AES-256-GCM before it is written to the database. GCM is authenticated, so any tampering with the stored ciphertext is detected on decryption. The encryption key lives outside the database, separate from the data it protects.
Secrets never leave the platform
Decrypted secrets exist only in memory for the duration of a scan. They are never included in exports, support sessions, audit logs, or API responses, and Beacon staff cannot retrieve them in plaintext.
Minimum permissions requested
Microsoft Graph Directory.Read.All
Microsoft Graph Policy.Read.All
Azure Resource Manager Reader
Azure Resource Manager Security Reader
No write permissions. No Contributor or Owner roles. Ever.

Audit and accountability

Every administrative action in Beacon is recorded in a tamper-evident audit log. Entries are chained with HMAC-SHA256: each record carries a keyed hash computed over its own contents plus the hash of the record before it. Deleting, reordering, or editing any entry breaks the chain at that point and every entry after it, so a single verification pass tells you whether the history is intact.

HMAC-SHA256 chain integrity
The chaining key is held server-side, so an attacker who reaches the database cannot recompute valid hashes to cover their tracks. A broken link points to the exact entry that was altered.
Comprehensive event coverage
Logins, logouts, password changes, role assignments, user management, client additions, and credential updates are all captured with actor, timestamp, and source IP.
Auditor-friendly export
Export the full log in a structured format that demonstrates control operation to auditors, without exposing raw credential data or internal system details.

Access control and tenant isolation

Beacon enforces strict access boundaries at every layer. Each client tenant's credentials and scan data are isolated from every other, and engineers see only the clients their team has been assigned. There is no path to another team's client data, even within the same MSP organisation.

Per-tenant credential isolation
Every client tenant has its own separately encrypted app registration secret. A scan for one tenant can only decrypt and use that tenant's credentials, so one client's access never reaches another's Azure environment.
TOTP MFA for all local accounts
Multi-factor authentication using a TOTP authenticator app is enforced for every user with a local Beacon account. Replay protection prevents one-time codes from being reused.
Team-scoped data isolation
Engineers are assigned to teams, and teams are granted access to specific clients. All API and UI access is enforced server-side, so there is no client-side filtering that can be bypassed.

Operational security

Beacon is designed to be secure by default at the infrastructure and application layer, not just in the features it exposes to users.

No agents in client tenants

Nothing is installed in client Azure environments. Beacon queries APIs remotely using the read-only app registration you provide.

Rate-limited authentication

Login, password reset, and TOTP endpoints are rate-limited and locked after repeated failures to prevent credential brute-force attacks.

HMAC-signed webhooks

All outbound webhooks, including PSA and notification integrations, are signed with a per-endpoint HMAC secret so your receiving systems can verify authenticity.

Cross-tenant isolation enforced server-side

Every write operation is verified against the authenticated user's organisation scope. There is no path to access another MSP's data, even with a valid session token.

Support sessions are scoped and logged

When Beacon support staff access your portal for troubleshooting, the session is scoped, time-limited, and recorded in your audit log, so you always know who accessed what and when.

Regular dependency updates

Beacon's dependencies are reviewed and updated regularly. Security patches are applied and released as priority updates, and you can track them in the changelog.

Responsible disclosure

If you discover a security vulnerability in Beacon, report it to us privately at the address below before disclosing it publicly. We acknowledge every report within 48 hours, give you a single point of contact, and keep you informed through to remediation.

We do not take legal action against researchers who report issues in good faith and give us reasonable time to address them before disclosure. Please do not access, modify, or exfiltrate data that is not your own while testing.

Report a vulnerability

Questions about security?

Our team is happy to discuss Beacon's security architecture in more detail before you sign up.

Contact us