Security at Continur

Last Updated: February 26, 2026

1. Overview

Continur is built on a zero-knowledge architecture. We monitor only metadata signals—event types, timestamps, and service names—to detect user activity. We never see, store, or have access to the content of your emails, messages, code, documents, or files.

Your Succession Map pointers are encrypted with keys derived per user. Even Continur engineers cannot decrypt your vault data. This page describes the specific technical controls behind that promise.

2. Encryption

All sensitive vault data uses envelope encryption powered by AWS Key Management Service (KMS):

Per-user data encryption keys (DEKs) — Each user gets a unique DEK generated and wrapped by KMS. Your DEK is never stored in plaintext.
AES-256-GCM field-level encryption — Individual vault pointer fields (credentials, access instructions, notes) are encrypted at the field level, not just at the database or disk layer.
Encryption at rest — DynamoDB stores all data with server-side encryption enabled. Vault pointers add a second layer of field-level encryption on top.
Encryption in transit — All traffic between your browser and our API flows over HTTPS/TLS. Internal service-to-service calls within AWS also use encrypted channels.

3. Authentication

Continur uses passwordless authentication via magic links. There are no passwords to store, leak, or breach.

Magic link login — A one-time link sent to your verified email address. No passwords, no password resets, no credential stuffing risk.
JWT validation — Every API request is validated by a Lambda authorizer that verifies the RS256 JWT signature, expiration, and claims before any data access occurs.
Successor two-factor release — Vault release requires both an email verification token and a separate SMS code delivered to the successor’s verified phone number. Both channels must confirm before any decrypted data is accessible.
Time-limited sessions — Successor release sessions expire after 72 hours. There are no permanent access tokens.

4. Activity Monitoring

Continur’s Pulse system watches for signs of life across services you connect. Here is what we do and do not access:

Metadata only — We read event types, timestamps, repository names, and calendar event existence. We never read email bodies, message content, code diffs, file contents, or DMs.
Read-only OAuth scopes — All integrations request the minimum permissions needed to detect activity. We cannot send emails, post messages, push code, or modify anything in your connected accounts.
Token lifecycle — OAuth tokens for GitHub App and X/Twitter integrations support automatic rotation. Tokens for all providers can be revoked instantly from your Pulse Sources dashboard, which also triggers upstream revocation with the provider.

5. Infrastructure

Continur runs on a fully serverless AWS architecture:

AWS Lambda — All API functions run as stateless Lambda invocations. There are no persistent servers, no SSH access, and no long-running processes to compromise.
Amazon DynamoDB — Fully managed NoSQL database with encryption at rest, automatic backups, and no direct network exposure.
Amazon CloudFront — CDN serves both the SPA and proxies API requests. All traffic terminates at CloudFront over HTTPS before reaching Lambda.
No self-managed servers — We do not operate EC2 instances, containers, or VMs. AWS manages patching, scaling, and physical security for all compute and storage layers.

6. Data Lifecycle

Activity records auto-expire — Pulse activity contexts carry a 30-day TTL in DynamoDB and are automatically purged after expiration.
Account deletion is complete — Deleting your account purges all associated data: vault pointers, encryption keys, metadata records, pulse sources, and successor information.
No retention tricks — We do not soft-delete data or retain it in hidden backups after you request deletion. When it’s gone, it’s gone.

7. Access Controls

Escalation race protection — DynamoDB conditional writes prevent duplicate or conflicting escalation state transitions. Only one escalation process can run per user at a time.
Least-privilege IAM — Each Lambda function has an IAM execution role scoped to the specific DynamoDB tables, KMS keys, and AWS services it needs. No function has blanket access to all resources.
No shared credentials — There are no static API keys, shared secrets, or hardcoded credentials in application code. All secrets are managed through AWS Systems Manager Parameter Store or KMS.
User isolation — All database queries are scoped to the authenticated user’s partition key. One user cannot access another’s data through the API.

8. Third-Party Services

We use a small set of trusted vendors, each with a limited scope of data access:

AWS (Lambda, DynamoDB, KMS, SES, CloudFront, Step Functions) — Hosts all infrastructure, manages encryption keys, and sends transactional emails. AWS processes encrypted data but cannot decrypt vault fields without our KMS key policy authorizing it.
Twilio — Delivers SMS messages for wellness checks, successor notifications, and release verification codes. Receives phone numbers and message text only. Does not access vault or account data.
xAI (Grok) — Classifies activity metadata to determine whether signals represent genuine user activity. Receives only activity type labels, timestamps, and service names. Never receives content, credentials, vault data, or personally identifiable information.

9. Contact

If you have security questions, want to report a vulnerability, or need details about our security practices, contact us at:

Verum SG LLC
Email: security@verumsg.com
General support: support@verumsg.com