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 modelCopy Anchor Link

The decryption path is constrained on three independent axes:

1. Write-only from the outside – once saved, a credential is never shown again: not in the Cotillion app, not in our staff console, not in any API response. It is decrypted only inside the Cotillion service that uses it, at the moment that service calls your CRM or partner program, each record sealed with its own data-encryption key, wrapped by a Customer Managed Key that never leaves AWS KMS's FIPS-validated hardware security modules.
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 one of the Cotillion services authorised to use the key, and retain the matching encryption context for each record.

What is encryptedCopy Anchor Link

• Autotask Secret (the API Key value generated in Autotask PSA).
• Autotask Username – encrypted as well, because Username + Secret is the full credential pair.
• ConnectWise Company ID, Public Key and Private Key – the API key pair and the company it belongs to.
• HaloPSA Client ID and Client Secret – the credential pair of the API application you create in your HaloPSA instance.
• 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 loggingCopy Anchor Link

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 transitCopy Anchor Link

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; a connection from outside it always arrives over TLS.

Never loggedCopy Anchor Link

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).

When a call to your system fails, the diagnostic we record is the integration, the failure class and the HTTP status the third party returned, never the credentials that authenticated it.

RevocationCopy Anchor Link

When a tenant removes an integration in the Cotillion UI:

1. The integration stops syncing at once. The record is marked deleted and no further sync runs. For a CRM / PSA connection the credentials make one last call, to remove the notification subscription Cotillion registered (below).

2. The encrypted credential material is cryptographically erased: ciphertext, IV, auth tag, wrapped data-encryption key and key reference are all set to NULL, which puts that record's unique data-encryption key permanently out of reach, even with full database access.

   Vendor connections (Microsoft Partner Center, AWS Partner Central) are erased in the same operation as the removal: the stored token is gone the moment you disconnect.

   CRM / PSA connections are erased moments later rather than in the same instant, and deliberately so: we use those same credentials one last time to delete the notification subscription we registered in your system. Erasing first would strand that subscription in your CRM with nothing able to remove it. In the normal case the teardown finishes and the credentials are erased within seconds. Where a system has no subscriptions to remove, or the confirmation is lost, a sweep that runs every quarter hour erases the credentials of any CRM / PSA connection removed more than six hours earlier.

3. Row metadata (organization id, integration type, deletion timestamp) is retained for audit purposes.

4. The third-party credential itself is not revoked on the third-party side (Autotask, AWS, etc.): that requires action by you in the third-party system, because Cotillion only ever has the access scope you grant, never the ability to modify the credential. Once the integration is removed you can safely disable or delete the API user at your end.

Data residencyCopy Anchor Link

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.

---

QuestionsCopy Anchor Link

For specific questions about credential handling, including audit artefacts, vendor security review, or coordinated disclosure of a vulnerability, contact security@indyrct.com. See Support → Responsible disclosure for how we handle reports.