Credentials handling

Every third-party credential Cotillion stores — Autotask API Username/Secret, AWS Partner Central role ARNs, Microsoft Partner Center OAuth refresh tokens, and so on — passes through the same KMS-envelope encryption pipeline. This page describes the guarantees that pipeline provides so security reviewers can sign off without needing source-code access.

Encryption model

The decryption path is constrained on three independent axes:

1. IAM identity — only one dedicated service identity is authorised to call kms:Decrypt. No human IAM principal can decrypt, including Cotillion engineers and SRE. The role is attached to a specific workload, not a shared utility role.
2. Encryption context — every encrypted record carries a per-tenant encryption context that AWS KMS verifies on each decrypt. A ciphertext stolen from one tenant cannot be decrypted in the context of another.
3. Region — the CMK is single-region (not multi-region). Backups or ciphertext copied to another AWS region cannot be decrypted there.

A leak of the database alone is therefore insufficient to recover any plaintext credential — the attacker would additionally need to compromise the specific workload that holds the IAM identity above, and retain the matching encryption context for each record.

What is encrypted

• Autotask Secret (the API Key value generated in Autotask PSA).
• Autotask Username — encrypted as well, because Username + Secret is the full credential pair.
• AWS Partner Central role ARN (built from the AWS account id you provide; the ExternalId is resolved per tenant at runtime, never stored).
• Microsoft Partner Center refresh tokens (when applicable).
• Any field on an integration record marked sensitive in the schema.

The integration’s public identifier (organization id, tenant id, external account id) is stored as plaintext because it carries no authentication value on its own.

Access logging

Every kms:Decrypt call is captured in AWS CloudTrail with the caller identity, timestamp, and the encryption context (which identifies the tenant whose credential was unsealed). CloudTrail flows to a dedicated audit account separate from the workload account, so a workload-account compromise cannot silently delete the access trail.

In transit

All outbound traffic to third-party APIs uses TLS 1.2 or higher. We do not pin certificates because the third-party hosts roll certificates on their own schedules; trust is provided through the public CA system.

Service-to-service traffic inside Cotillion is restricted to a private network; cross-boundary connections always terminate at a TLS-fronted ingress.

Never logged

The credential pipeline redacts sensitive fields before log lines leave the originating process. The redaction list covers:

• Common credential field names — secret, API key, password, access / refresh tokens.
• Standard authentication headers — Authorization, Cookie, and any vendor-specific header carrying an API key.
• Any field whose name matches a sensitive-token pattern (e.g. ending in Secret, Token, Password).

Outbound HTTP requests log the request envelope (method, URL, headers with secrets redacted, response status) for audit purposes; the body is omitted when it carries a credential payload.

Revocation

When a tenant removes an integration in the Cotillion UI:

1. All encrypted credential material is wiped from the database immediately — ciphertext, IV, auth tag, wrapped data-encryption key, and key reference are all set to NULL. This is cryptographic erasure: the unique data-encryption key used for that record’s credentials becomes permanently unreachable, even with full database access.
2. Row metadata (organization id, integration type, deletion timestamp) is retained for audit purposes.
3. The third-party credential itself is not revoked on the third-party side (Autotask, AWS, etc.) — that requires action by the tenant in the third-party system, because Cotillion only ever has the access scope you grant, never the ability to modify the credential.

Data residency

All credentials are stored exclusively in the ap-southeast-2 (Sydney) AWS region. They are never replicated to any other region. The CMK itself is single-region, so the encrypted data is cryptographically unrecoverable outside ap-southeast-2 even if backups were physically removed from the region.

In the unlikely event of a complete ap-southeast-2 regional failure, application data restored from backup remains intact, but tenant credentials require re-entry. This is a deliberate trade-off favouring credential isolation (single-region key material) over cross-region restorability.

Last reviewed: 2026-05-28

Questions

For specific questions about credential handling — including audit artefacts, vendor security review, or coordinated disclosure of a vulnerability — contact [email protected]. See Support → Responsible disclosure for how we handle reports.