Security Model
Two independent layers
Both must pass before any access succeeds, on every cloud.
Layer 1: Identity (CE side)
Engineers authenticate to continuous.engineering's own identity provider with MFA before they can attempt anything. This happens on our infrastructure: you do not manage our engineers' credentials, and MFA is enforced there, once, at login. When an engineer leaves CE, their access is revoked centrally and they immediately lose access to every client account, project, and subscription.
We're upfront about one platform limitation here rather than overclaiming: federated/SSO sessions don't reliably carry a "recent MFA" flag through to the receiving cloud's own trust evaluation, on any of the three clouds. That means none of AWS, GCP, or Azure can independently re-verify "this specific session completed MFA in the last hour" at the trust boundary; a second MFA condition there would be a check that can never usefully pass or fail, not an extra layer of real security. What every client can verify: that MFA is a hard requirement at our own SSO, enforced technically (not by policy someone could quietly skip), for every engineer, every session.
Layer 2: Confused-deputy protection (client side)
This is the layer that stops our identity provider from being tricked into acting on someone else's behalf, and it's implemented differently per cloud:
- AWS: every role assumption must present an ExternalId (
continuous.engineer). Without the correct ExternalId, AWS rejects the call outright, regardless of who's asking. See the FAQ for the full explanation of why this matters. - GCP: access is scoped to a specific Workforce Identity Federation provider, one per tier: an identity that authenticated through the wrong provider simply isn't bound to any role in your project. There's no separate secret to present; the provider binding itself is the check.
- Azure: there's no "assume a role" step to spoof in the first place. Access exists because a specific engineer was invited as a guest and role-assigned directly; the invitation and the role grant are the same act.
What we can access
Only resources in accounts/projects/subscriptions you have explicitly onboarded, through the roles you have granted, during active sessions (AWS/GCP: 2-4 hour tokens; Azure: standing until revoked, same as any guest collaborator access; see role reference for why Azure's session model differs).
What we cannot access
- Any account, project, or subscription you have not onboarded
- Resources tagged
env-prod=trueif you have attachedCE-DenyProdto our roles (AWS/GCP; not yet available on Azure, see FAQ) - Instances not tagged
database=truewhen usingCE-Data - Anything not covered by the assigned role's policy
What we never have
- Long-lived access keys
- SSH keys to your servers
- Passwords to any of your systems
- Access that survives revocation on your end
Revoking access
| Cloud | Action | Effect | Time |
|---|---|---|---|
| AWS | Delete the CloudFormation stack | All CE roles removed | Immediate |
| AWS | Attach CE-DenyProd to a role | Prod access blocked for that role | Immediate |
| GCP | ./gcp-deploy.sh --project <id> --remove | All CE bindings removed | Immediate |
| Azure | ./azure-deploy.sh --subscription <id> --remove | All CE role assignments removed | Immediate |
| Any | Contact us to offboard | Your account/project/subscription removed from our side (AWS) | Immediate |
Active AWS/GCP tokens issued before removal expire within their remaining lifetime (max 4 hours). Azure guest role assignments stop working the moment they're removed; there's no token to wait out.
Network access
No open ports on any cloud, though the mechanism differs:
| Cloud | Mechanism |
|---|---|
| AWS | AWS Systems Manager Session Manager, over HTTPS port 443. Port 22 stays closed, your security groups don't change. |
| GCP | Identity-Aware Proxy (IAP) TCP tunneling, over HTTPS. No firewall rule needs to allow inbound SSH. |
| Azure | Azure Bastion with Entra ID authentication. No public IP or open port 22 on the VM. |
Monitoring
Maturity differs by cloud today, and we'd rather tell you that plainly than let you assume parity:
- AWS: the stack creates a dedicated CloudWatch log group that receives only CE role events, plus a 17-widget dashboard covering live alarms, per-role trends, a full activity feed, and anomaly detection. See the monitoring guide.
- GCP: every CE action appears in your project's Cloud Audit Logs under the federated identity, queryable the same way any other project activity is. No dedicated CE dashboard yet.
- Azure: every CE action appears in your subscription's Activity Log under the individual guest's identity, with sign-in activity visible in your tenant's Entra ID logs. No dedicated CE dashboard yet.
AWS's monitoring tooling is the most mature of the three because it's been in production longest; GCP and Azure dashboards are on the roadmap, not something we're pretending already exists.