Security
This page is the security overview for Cloud Customers - written for the people evaluating whether Evolving Edge is suitable for a given workload, and specifically for security, compliance, and procurement teams running a vendor risk review. It summarizes the platform’s security posture in customer-facing terms; the full technical detail - architecture diagrams, threat model, cryptographic primitives, and steps your own security team can use to verify these claims independently - lives in the Security Whitepaper below.
The short version
Section titled “The short version”Evolving Edge’s network runs on Edge Nodes - devices owned and operated by independent third parties, not by Evolving Edge (see Edge Node in the Glossary). That’s the source of the network’s latency and cost advantage, but it also means the security model can’t simply assume the hardware serving your content is trustworthy by default. The platform is built around a tiered encryption model that lets you choose, per workload, how much trust you place in that infrastructure - up to and including a mode where neither an Edge Node nor Evolving Edge’s own control plane can ever read your content.
How content is protected: the three encryption levels
Section titled “How content is protected: the three encryption levels”Every workload is published at one of three encryption levels, chosen per deployment target. This page describes them in security terms; see Workloads for how to configure them.
| Level | Can an Edge Node ever see plaintext? | Guarantee type | Best for |
|---|---|---|---|
| Level 0 - Public | Yes, always - the same as any conventional CDN | N/A | Public sites, assets, anything already suitable for a public CDN |
| Level 1 - Encrypted | No, never, under any circumstance - including by Evolving Edge’s own control plane | Cryptographic | Content where you need zero server-side trust, Evolving Edge included |
| Level 2 - Double | Only transiently, on the specific node handling an authorized request, for the life of that request | Procedural (audited, time-bounded) | Gated/paid content that needs centralized revocation |
The distinction between Level 1 and Level 2 is the single most important thing to take away from this page: Level 1’s confidentiality holds even if Evolving Edge’s own infrastructure were compromised, because the decryption key is never sent to any server - it travels in the URL and is used only inside the requesting browser. Level 2 trades that for the ability to revoke access centrally, which means a short, audited plaintext exposure window exists on whichever Edge Node handles a given request. If that tradeoff matters for a specific workload’s threat model, the Whitepaper’s Section 12 (“Known limitations, stated directly”) and Section 9 (“Operator trust boundary”) walk through it in full.
What an Edge Node operator can and can’t see
Section titled “What an Edge Node operator can and can’t see”This is the question most reviewers ask first. In short: an operator cannot read Level 1 content under any circumstance, and cannot attribute any cached content - Level 0, 1, or 2 - to a specific customer, since no customer-identifying metadata exists in the cached file or its filename. For Level 2, an operator with privileged access to their own hardware could observe plaintext during an in-flight request on their machine; every access-token issuance that makes that request possible is logged and reviewable by you through the audit feed, and access tokens default to a 30-second lifetime. The Whitepaper’s Section 9 has the full breakdown, including what’s on an Edge Node’s disk, in memory, and on the wire at each encryption level.
Compliance and data handling
Section titled “Compliance and data handling”- SOC 2 Type II - Evolving Edge is pursuing SOC 2 Type II attestation. As of this writing, that attestation has not yet been completed; the architecture already maps to the relevant Trust Services Criteria (Whitepaper Section 11.2), and outstanding work includes formalizing incident response and completing an independent observation-period audit.
- HIPAA - The platform is architected with HIPAA-relevant workloads in mind, principally through Level 1: PHI processed under Level 1 is never held in plaintext by any Evolving Edge- or operator-run system component. A formal Business Associate Agreement (BAA) program isn’t established yet - if you have HIPAA requirements, contact Customer Support to discuss your workload ahead of a formal BAA offering. Current guidance is to process PHI under Level 1 rather than Level 2.
- Incident response - Evolving Edge’s incident response process is operational today but not yet formalized into a published runbook with defined severity tiers and notification timelines; that formalization is part of the SOC 2 Type II work above.
- Vulnerability disclosure - Security researchers and customers can report findings to
security@evolvingedge.ai; reports are acknowledged within one business day.
We’d rather state where we are plainly than imply a maturity level we haven’t reached yet - this section will be updated as each milestone above is reached.
Security Whitepaper
Section titled “Security Whitepaper”The full Evolving Edge Security Whitepaper covers the platform architecture, threat model and trust boundaries, the .ee workload format and cryptographic primitives, network security, audit and monitoring, and a set of checks your own security team can run independently - without needing Evolving Edge’s cooperation - to verify the claims on this page. This is the primary reference document for a formal vendor security review.
Download the Security Whitepaper, Two Strangers, One Machine (PDF, 2 MB)
Questions
Section titled “Questions”For anything not covered here - custom SLAs, DPAs, or a workload that needs a conversation before you commit to an encryption level - reach out via Customer Support.
Next: Customer FAQ >