Cryptographic and operational rigor, named and auditable.

Cryptographic primitives

Primitive	Role
ChaCha20-Poly1305	Application-layer authenticated encryption (AEAD)
X25519	Ephemeral key exchange
HKDF-SHA256	Key derivation
SPIFFE / X.509 SVID	Workload identity, rotated every 24h
QUIC + TLS 1.3	Transport (HTTP/2 fallback for restrictive networks)
Cosign	Container image signing
Sliding-window replay protection	Anti-replay at the Hub edge

Identity model

Ewii uses SPIFFE workload identity. Every Client and every Hub workload has a SPIFFE identifier (SPIFFE ID), backed by a short-lived X.509 SVID. SVIDs are issued by ewii’s per-tenant SPIFFE issuance service, scoped to the customer’s trust domain, and validated by the Hub at every connection. Each tenant’s trust domain has its own X.509 root CA, held inside the same Hub deployment but encrypted at rest under the operator’s master key — a SVID issued in tenant A’s trust domain does not validate against tenant B’s trust bundle. There are no shared secrets, no static API keys, and no long-lived credentials in any deployment.

SVID validation is per-connection (handshake) today. Session keys derived from the validated identity bind every subsequent payload to that identity. SVIDs are delivered to Clients over a SPIFFE-conformant HTTPS enrollment + renewal protocol (not the stock Workload-API Unix socket, which would require co-residence of issuer and Client). Default SVID lifetime is 24h with renewal at 66 % of validity. A per-request SVID re-check is on the v1.1 roadmap; the trust-center-manifest.json carries the authoritative version state.

Threat model summary

Our threat model assumes: (1) the relay is observable but compromised; (2) the operator’s Hub host is trusted but auditable; (3) the customer’s Client host is trusted to the same level as their database. Under those assumptions, Ewii guarantees confidentiality of payload data (defense-in-depth encryption), authenticity of every connection (SPIFFE), and replay-resistance (sliding-window). The full threat model document is in the Trust Center pack.

On-premise credential custody

Database credentials never leave the customer’s premises. The on-premise MCP Adapter holds an AES-256-GCM-encrypted credential store at rest; the encryption key is derived locally from the deployment’s enrollment token and workspace identifier via PBKDF2-SHA256 (100,000 iterations). The Hub does not receive plaintext credentials at any point. The relay does not see them. A compromise of the operator’s SaaS infrastructure cannot expose them, because the operator’s SaaS infrastructure never possesses them.

Operationally this means rotating a database password is a customer-local action. Whether the customer rotates it through the on-premise Adapter admin UI or by re-deploying the package with a new databases.json, the new value takes effect immediately and is never transmitted in plaintext or logged in transit. Audit events still flow — the operator’s console records that a credential was rotated, with the actor and timestamp — but the value itself is opaque to the operator.

For regulated buyers, this is the property that makes the security review tractable. The operator cannot exfiltrate what the operator never holds. The procurement office can answer the “where do the keys live” question with a single sentence and a pointer to the on-premise component diagram.

Compliance posture

Canadian Protected B-aligned. ITSG-33 control mapping available. SOC-2 status is self-attested today against the Security and Confidentiality trust service criteria; a third-party audit is on the roadmap with a target year of 2027. The trust-service criteria we do not claim (Availability, Processing Integrity, Privacy) and the reasoning behind each omission are enumerated in the trust-center-manifest.json. CAIQ-Lite and SIG-Lite questionnaires pre-answered in the Trust Center pack. PCI-DSS scope analysis available on request. HIPAA/PHIPA mapping documented; we enter into BAAs with healthcare operators on request.

Cryptographic agility — FIPS and post-quantum posture

Our default suite (ChaCha20-Poly1305 + X25519 + HKDF-SHA256) is the engineering-strength modern choice. We recognize two parallel demands from regulated buyers and we are honest about where each one sits today:

• FIPS 140-3 path. An AES-256-GCM suite alternative is under engineering review for customers whose procurement requires FIPS-validated primitives. It is not shipped in v1. If FIPS validation is a hard requirement for your environment, raise it at the Architecture Review and we will sequence it against your timeline.
• Post-quantum. A PQ-hybrid construction (X25519 + Kyber-768) is on the engineering review track with a target year of 2027, contingent on standards stabilization and customer demand. Until then, ephemeral X25519 carries forward-secrecy for current sessions; a future PQ migration does not invalidate prior traffic.

Both items are tracked in the trust-center-manifest.json under cryptographic_agility. Targets in that document are engineering roadmap signals, not contractual commitments; concrete commitments are negotiated per engagement.

Vulnerability disclosure

Our Vulnerability Disclosure Policy is documented in the Trust Center pack. Machine-readable metadata: /.well-known/security.txt (RFC 9116). To report a vulnerability, email security@delta-telematics.ca with details. We acknowledge within one business day and we coordinate disclosure timing.

Researcher acknowledgements

We publicly recognize security researchers who report valid issues. No researcher has been listed yet — this section becomes a roll as we receive valid disclosures.