Security & trust

Security built into the platform,
not bolted on.

Beacon reaches your clients' Azure, AWS, and GCP accounts through one read-only, least-privilege connection per cloud: an Azure App Registration, an AWS cross-account IAM role, or a GCP scanner service account. Stored secrets are encrypted with AES-256-GCM, every administrative action lands in a tamper-evident audit log, and each client'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. Each cloud connects through a single read-only, least-privilege path — an Azure App Registration (or an admin-consented multi-tenant app), an AWS cross-account IAM role assumed on demand, or a Viewer grant on Beacon's GCP scanner service account. Beacon can read posture but cannot change a single setting. Where a secret is involved it is encrypted before it ever touches disk, and for AWS, GCP, and Azure admin-consent connections no long-lived key is stored at all.

Least-privilege, read-only access
Across Azure, AWS, and GCP, Beacon requests read and reporting access only — Microsoft Graph read scopes and Azure Resource Manager Reader, an AWS role scoped to read APIs, or GCP Viewer. No write, Contributor, or Owner permission is ever requested, so Beacon can read posture but cannot change a single setting in your environment.
No long-lived cloud keys stored
AWS connections store only a role ARN and an external ID — Beacon assumes the cross-account role on demand and never holds an access key. GCP stores only the scope to scan; the trust is an IAM grant on Beacon's scanner service account, so there is no key file. Azure admin-consent connections likewise store no secret.
AES-256-GCM encryption at rest
Where a secret is stored — an Azure App Registration client secret or certificate — it 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.
TLS 1.2+ encryption in transit
All connections use TLS 1.2+. Traffic between Beacon's services and its database is encrypted in transit, so credentials and scan data are never carried over the network in the clear.
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.
How Beacon connects to each cloud
Azure Read-only app
A read-only App Registration (client secret or certificate), or an admin-consented multi-tenant app with no stored secret.
AWS Cross-account role
A cross-account IAM role assumed on demand, locked to your account with a unique external ID. No access keys are stored.
GCP Viewer grant
A Viewer grant on Beacon's scanner service account, at organisation or project scope. No service-account key file is stored.
Azure read-only permissions
Microsoft Graph Directory.Read.All
Microsoft Graph Policy.Read.All
Microsoft Graph AuditLog.Read.All
Microsoft Graph SecurityEvents.Read.All
Azure Resource Manager Reader
A handful of additional read scopes apply when you enable Intune, Exchange Online, SharePoint, or Teams checks — the onboarding wizard lists every permission and verifies each one. All are read-only: no write, no Contributor or Owner, 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-client credential isolation
Every client has its own separately stored connection — a separately encrypted Azure secret, its own AWS role and external ID, or its own GCP scope. A scan for one client can only use that client's credentials, so one client's access never reaches another's cloud environment.
TOTP MFA and single sign-on
Multi-factor authentication using a TOTP authenticator app is enforced for every user with a local Beacon account, with single-use recovery codes and replay protection that prevents one-time codes from being reused. Organisations can also enforce SAML single sign-on, where assertions are single-use within their validity window.
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 environments

Nothing is installed in client Azure, AWS, or GCP environments. Beacon queries each cloud's APIs remotely using the read-only connection you provide.

Rate-limited authentication

Login, password-reset, and two-factor endpoints are rate-limited per account and per IP, and repeated failures raise an alert, to blunt credential brute-force and stuffing 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