Read-only by design. Verifiable by you.
With the recommended IAM-role connection, CloudArq never holds long-lived credentials — scans use ExternalId-scoped STS AssumeRole. CloudArq never reads the data inside your resources. Here's exactly how it's built — and how you can check.
AES-256-GCM at rest
Every stored finding is sealed with authenticated encryption. We persist results — never your account data, app data, or S3 objects.
Read-only IAM role
We assume a role scoped to describe / list actions only. The audit is read-only — there is no write path.
ExternalId on every assume
Each role assumption is scoped with your unique ExternalId, closing the confused-deputy gap so no one else can borrow our access.
GDPR export & delete
Export everything we hold, or permanently delete it, on demand. EU-hosted in Helsinki — your data stays in the EU.
Published subprocessors
Our full subprocessor list is public and kept current. You always know exactly who can touch your data, and where.
Nothing installed
No software to deploy, patch, or trust running inside your VPC. CloudArq talks to AWS APIs from the outside — nothing lives in your account.
You don't have to take our word for it
You deploy the role yourself from a public template you can read line by line — we never hold a key to your account. It grants AWS’s own read-only audit baseline, then adds an explicit Deny over every action that could reach your actual data.
That Deny is the part worth knowing about: AWS evaluates it before any permission, and nothing can override it — not a future AWS change, and not us. So this isn’t a promise we’re asking you to trust. It’s a rule living in your account, which you can verify there whenever you like.
How we access your AWS account
CloudArq connects to your AWS account with an IAM Role via STS AssumeRole — the same mechanism AWS recommends for cross-account access — so CloudArq never holds long-lived credentials. No access key is ever created or stored.
You create a read-only IAM Role
In your AWS account, you create a role with only the permissions CloudArq needs. We provide the CloudFormation template.
STS AssumeRole with External ID
CloudArq assumes the role using AWS STS with your unique External ID — preventing confused deputy attacks. Access is via short-lived STS session credentials; no long-lived access key is ever created or stored.
Read-only scan, nothing stored
We scan your infrastructure using read-only API calls. No modifications are ever made. Temporary credentials are discarded after the scan completes.
The exact read-only policy you'd grant
Below is the live CloudFormation template our connect flow deploys — fetched in real time from where we publish it, so what you read here is exactly what you'd create in your account. Don't take our word for it; read the policy before you sign up.
We couldn't load the template inline right now. View the exact template here →
What we store, what we don't, where
We follow the principle of least privilege — collecting only what's needed and encrypting everything.
What We Store
Audit results, finding metadata, and compliance scores. We store the minimum data needed to show you results and track trends over time.
What We Never Store
Raw AWS credentials in plaintext, customer application data, database contents, S3 object data, or any secrets from your infrastructure.
Data Retention
Audit data is retained as long as your account is active. When you delete a connection or your account, all associated data is permanently removed within 30 days.
Security in every layer
Encryption at Rest
- AWS credentials, TOTP secrets, and per-org ExternalIds encrypted at rest with AES-256-GCM (random IV per operation)
- Encryption keys managed with strict access controls and rotation
- Automated daily database backups with retention policy
Encryption in Transit
- TLS 1.2 or higher enforced on all connections
- SSL termination via Cloudflare Full (Strict) mode
- HSTS enabled with preload for all domains
- Internal services communicate over isolated Docker network
Credential Handling
- Read-only IAM Role + ExternalId is the only connection method
- External IDs prevent confused deputy attacks
- Short-lived STS session credentials — no long-lived key is ever created or stored
Infrastructure
- Origin server on a Hetzner dedicated host in Helsinki, Finland (EU), fronted by Cloudflare's global edge network
- All services run in isolated Docker containers
- Network access restricted with strict firewall rules
- Content Security Policy headers enforced on all responses
Access Control
- Role-based access control (RBAC) with admin and client roles
- Two-factor authentication (TOTP) with backup codes
- JWT session management with short-lived access tokens
- Audit logging for all administrative actions
Application Security
- Rate limiting on all sensitive endpoints
- SQL injection prevention via parameterized queries (SQLAlchemy ORM)
- XSS prevention via strict CSP headers
- CORS restricted to authorized origins only
Where the read-only audit lands
A look at the signed-in app shell — every surface is fed by the same read-only scan. · illustrative example
In the shipped build this lists real scans for production-account. Score, waste, and findings are wired to live data.
live in productionSettings is a hub linking profile · security · notifications · data & privacy · team · preferences · SSO · trust-center · custom-frameworks · organizations.
Security Contact
If you discover a security vulnerability or have concerns about our security practices, please contact us directly. We take every report seriously and respond per our coordinated disclosure policy.
[email protected]