Encryption and key handling

A vendor that sells cryptographic inventory should be able to describe its own cryptography without flinching. This article covers how AutoPQC protects data in transit and at rest, how workspaces are separated, how credentials supplied for authenticated discovery are stored and scoped, how secrets are handled in our own build and run pipeline, and what we would do about a requirement for customer-managed keys.

#In transit

Every connection to the application, the API and the discovery workers is encrypted. There is no plaintext listener, no plaintext fallback and no internal hop that runs unprotected because it is inside a network boundary. Service-to-service traffic inside the platform is authenticated and encrypted on the same basis as traffic arriving from the internet, because a flat internal network is a single compromise away from being a public one.

Our accepted protocol versions and cipher suites track the transition guidance in NIST SP 800-131A rather than a preference of our own, and the accepted set is narrowed over time rather than widened. The current floor is [PLACEHOLDER: minimum accepted TLS version and cipher suite policy]. Authenticated discovery originates from [PLACEHOLDER: egress address range for discovery workers], which you can allow-list.

#At rest

Data at rest is protected in two layers. Storage-level encryption covers everything, and envelope encryption covers the small subset of records that would matter most if the storage layer were bypassed: discovery credentials, detector evidence and export artefacts. The second layer exists because storage-level encryption defends against a stolen disk, not against a compromised application.

Primary datastore

Volume and object encryption provided by [PLACEHOLDER: cloud infrastructure provider and region], using [PLACEHOLDER: at-rest algorithm and key length]

Discovery credentials

Envelope-encrypted per workspace under a wrapping key held in [PLACEHOLDER: key management service]; ciphertext only in the datastore, never written to application logs

Detector evidence and exports

Envelope-encrypted under the same per-workspace hierarchy, with the plaintext existing only in worker memory for the duration of a job

Backups and snapshots

Encrypted to the same standard as the primary store; keys separated from the restore operators, access limited to the documented restore path

Key rotation

Data-encryption keys rotated every [PLACEHOLDER: DEK rotation interval]; wrapping keys every [PLACEHOLDER: KEK rotation interval]; rotation is automated and logged

Cryptographic implementation

Platform-provided modules, validated where the deployment target offers a validated build — [PLACEHOLDER: validated cryptographic module and certificate number]

#Tenant separation

Workspaces are logically separated, and the separation is enforced below the query layer so that a forgotten filter in a new feature cannot leak across it. Encryption reinforces the boundary: each workspace has its own data-encryption key, so a record read out of context is ciphertext rather than another customer’s inventory.

• Every persisted record carries a workspace identifier, and the data access layer refuses a read that does not name one.
• Per-workspace data-encryption keys, wrapped by a key hierarchy that no single service holds in full.
• Discovery jobs run in a worker scoped to one workspace for their lifetime; credentials are never resident in a process that serves another tenant.
• Cross-tenant isolation is covered by our own regression suite and by [PLACEHOLDER: independent penetration test date and testing firm].
• Physically separate deployment for customers who require it is [PLACEHOLDER: availability and commercial terms for single-tenant deployment].

#Credentials supplied for authenticated discovery

Authenticated discovery is the one place where a customer hands us a secret, so it gets the strictest handling in the platform. The shape of the arrangement matters more than the storage: a narrow, short-lived, revocable credential is safer than any amount of encryption applied to a broad standing one.

• Written scope first. No credential is accepted before a scope document naming the environments, the read-only permissions and the window is agreed. What to have ready before we start lists what that document contains.
• One identity per environment. No sharing across environments, no reuse of a human’s account, no interactive login.
• Read-only, always. Discovery reads configuration. Write, delete and administrative permissions are refused, and a credential that carries them is sent back rather than downgraded on our side.
• Entered once, never shown again. Credentials are submitted through the application, envelope-encrypted on receipt, and never rendered back into the interface, an export, a support ticket or a log line.
• Decrypted only in worker memory. The plaintext exists inside a discovery worker for the duration of a job and is not written to disk.
• Revocable without us. You revoke at your identity provider or cloud console at any time. Discovery fails closed and reports the failure rather than retrying with anything else.

#Why short-lived and least-privileged access is the preference

A standing credential quietly becomes an undocumented dependency. It survives the person who created it, it appears in no one’s review, and its blast radius grows as the estate changes around it. Short-lived access inverts all three properties. When we discuss access at the start of an engagement, we work down this ladder and stop at the first rung your environment supports.

1. 01Workload identity federation. No long-lived secret exists at all; the worker exchanges a signed assertion for a short-lived token scoped to the discovery role.
2. 02Short-lived tokens issued per job. A secret exists, but its lifetime is measured against the job rather than the contract.
3. 03Time-boxed service account. A standing credential with an expiry date recorded in the scope document and enforced by your identity provider, not by our diary.
4. 04Standing read-only account. Accepted where nothing above is available, on the condition that it appears in your access review and that we are told when it is rotated.

Federation and token exchange sit alongside single sign-on for human access; Single sign-on and API and automation surfaces describe the identity paths for people and for machines respectively.

#Secrets in our own pipeline

The controls above are worth little if a deployment key sits in a repository. Our own secret handling is deliberately unremarkable, which is the highest compliment an engineer can pay it.

• No secrets in source control. Every commit and every pull request is scanned, and a detection blocks the merge rather than filing a ticket.
• Build and deploy identities are short-lived, scoped to one pipeline stage, and issued per run. There is no shared production password to leak.
• Production access for engineers requires single sign-on plus a hardware-backed second factor, with [PLACEHOLDER: privileged access approval and session recording policy].
• Dependencies are monitored against the GitHub Advisory Database and CISA’s Known Exploited Vulnerabilities catalogue, with remediation targets published in the Assurance Center.
• Customer inventory data is not used to train or fine-tune our classification models without a separate written agreement. The corpus behind our published 95.2% classification accuracy and 0.94 macro-F1 is described in [PLACEHOLDER: composition of the labelled training and evaluation corpus].

#Customer-managed keys

Roadmap. Customer-managed keys are not generally available. [PLACEHOLDER: target date for customer-managed key support]. Rather than describe a feature that does not exist, here is the design we would build and the trade-offs we would ask you to accept, so that a procurement review can judge it now.

• Your key in your key management service wraps the per-workspace data-encryption key. We hold ciphertext and a key reference, not the key.
• Revoking the grant is a deliberate denial of service against your own workspace. Findings become unreadable within [PLACEHOLDER: cache expiry after key revocation], and that is the intended behaviour rather than a fault.
• Some conveniences degrade. Search indexes, cross-workspace trend views and point-in-time restore all depend on readable data, and each would need an explicit decision.
• Backups inherit the constraint. A restore after revocation recovers ciphertext only, which changes what a disaster recovery commitment can promise.
• Until it ships, the levers that actually reduce exposure are available today: send less by choosing unauthenticated discovery, shorten retention under Retention and deletion, or run a narrower scope.