Transparent Edge and the second CNAME: can sovereignty ride on someone else’s network?

Summary

• Transparent Edge Services S.L. is an active Madrid company whose legal continuity begins in 2008, while the current brand and operating perimeter emerged through a 2021 absorption of Transparent CDN and Raipson Security into the former ServoTIC company. The official merger record is narrower and more precise than the company’s shorthand description of three businesses merging into a newly founded enterprise.
• The product is not merely bandwidth resale. Transparent Edge supplies a policy and support layer around Varnish Enterprise: DNS onboarding, cache logic, origin selection, WAF and DDoS controls, logs, an API, and managed changes. That programmability is useful, but Varnish is a foundational supplier dependency rather than a replaceable component.
• The company says it operates more than 70 points of presence in more than 40 countries. Public routing evidence independently confirms one company-originated IPv4 prefix, two observed upstreams, and no company-originated IPv6 prefix. Public DNS observations also show Transparent Edge customer aliases resolving onto DataCamp/CDN77 infrastructure. Those findings support a real operating network but do not independently verify the full PoP count, ownership, dedicated capacity or jurisdictional treatment of every node.
• “European sovereignty” must be contracted as a data-flow property, not accepted as a corporate-nationality slogan. The company’s public global node list includes locations outside Europe, while its sovereignty page says data remains in the European Union. That tension may be resolvable through regional steering, dedicated or licensed deployments, or a distinction between payloads, caches, control data and logs; the public material does not define the boundary tightly enough.
• The standard CDN price claim is simple—one per-gigabyte rate regardless of geography and no request charge—but the full portfolio is not priced by one unit. WAF is described as request-billed, dedicated CDN adds fixed server fees, support packages add recurring cost, and public numerical rates are not disclosed. Buyers need a bill simulation based on cache misses, attacks, logs, purge activity, support and origin egress, not only delivered gigabytes.
• Transparent Edge can be a credible second delivery leg or a local managed layer for organisations that value Spanish and English engineering access, VCL flexibility and European contracting. It is not automatically an independent second leg if it is simply placed in front of CloudFront or if both paths share the same transit, DNS, origin, certificate or configuration dependencies.
• The decisive procurement evidence is obtainable but should be requested before commitment: node and subprocessors by service, cache and log residency, certificate scopes, tested DDoS capacity, support staffing and escalation, status and incident history, Varnish licensing continuity, configuration blast-radius controls, and an exit package that translates customised VCL and security policy into a portable form.

The second CNAME

Transparent Edge’s customer journey begins with a DNS change. Its documentation assigns a hostname in the form <SERVICE>.<CLIENT_ID>.edge2befaster.net, and tells the customer to replace the public website’s existing address record with a CNAME pointing to that service hostname. The change is conceptually modest: visitors ask for the customer’s domain, DNS hands them to Transparent Edge, and the edge platform either serves a cached response or goes back to the customer’s origin.

That first CNAME is the commercial handover. A second CNAME, visible deeper in public observations, reveals the operating question.

A public URLScan record for a European hostname shows caching.c472.edge2befaster.net as its alias and places the observed service addresses in AS60068, operated by DataCamp Limited and associated with CDN77/DataPacket. That single record is not a map of Transparent Edge’s whole network. DNS answers can vary by requester, geography, time, product and traffic policy. Yet it is valuable because it demonstrates that at least some delivery paths bearing Transparent Edge’s customer namespace use address space and routing operated by another infrastructure company.

This is not unusual or inherently disqualifying. A smaller CDN can lease servers, capacity, transit and facilities while retaining its own cache software, control plane, customer policy, support and commercial contract. Many infrastructure businesses assemble services from specialised layers rather than owning every fibre and building. The relevant distinction is not “owned” versus “fake.” It is which party controls each failure domain, which party can see data, and which promises survive when an upstream supplier changes.

Transparent Edge’s proposition therefore has to be evaluated at four levels.

First is the customer-facing control layer: configuration, VCL policy, security rules, analytics, API access, support and billing. Second is the cache and compute layer: the machines that terminate TLS, inspect requests, store entities and execute edge decisions. Third is the network layer: address space, transit, anycast or DNS steering, interconnection and DDoS absorption. Fourth is the legal and operational layer: the companies, locations, subprocessors, certificates and staff that can access or change the service.

A hyperscale CDN often bundles those layers behind one giant brand, which can make the service easy to buy but difficult to inspect. Transparent Edge offers a more personal and programmable alternative. The second CNAME is a reminder that personal access does not by itself collapse the supply chain. The boutique provider must be more explicit about the chain precisely because sovereignty and transparency are central to its sales argument.

A 2021 brand on a 2008 legal spine

The current legal identity is well supported. Transparent Edge’s terms of use name TRANSPARENT EDGE SERVICES, S.L., Spanish tax identifier B85363141, at Calle Cedaceros 11, 6ºC, Madrid. They cite Madrid Mercantile Registry sheet M-460149. The Bloomberg LEI record independently lists the same legal name, address and registry identifier, classifies the entity as active, and gives an entity creation date of April 3, 2008.

That 2008 date initially appears to conflict with the company’s statement that Transparent Edge was founded in 2021. The merger record resolves the apparent contradiction.

An official preliminary notice published in August 2021 identifies ServoTIC Backup Appliance Solutions S.L.U. as the absorbing company and states that it had been renamed Transparent Edge Services S.L.U.. The final official notice says shareholders approved the absorption of Transparent CDN S.L. and Raipson Security S.L. by Transparent Edge Services S.L.U. on September 1, 2021. The absorbed companies transferred their assets universally and were dissolved without liquidation.

The verified formulation is therefore: a legal company originating in 2008, formerly trading as ServoTIC Backup Appliance Solutions, became Transparent Edge Services and absorbed the CDN and security companies in 2021. The company’s own merger announcement describes a commercial integration beginning in February and presents Transparent CDN, ServoTIC and Raipson as three related businesses that had already collaborated and shared shareholders. It says the combination created a company spanning hosting, content delivery, cybersecurity and systems administration under one operating brand.

This lineage matters to a buyer for three reasons.

It explains why the brand can be young while claiming more than a decade of operating experience. It also indicates that the company’s capabilities were assembled from distinct technical cultures: CDN engineering, systems architecture and security. Finally, it makes the legal counterparty more durable than a literal reading of “founded in 2021” would imply, while warning against assuming that every product has been operated in its current form since 2008.

The brand perimeter is broad, but the public evidence does not show a complex corporate group with many regional subsidiaries. The legal terms point to one Spanish contracting company. A commercial database consulted in June 2026 classifies it as an active small enterprise and estimates 11 to 25 employees and a €1.5 million to €3 million turnover band. Those figures are database estimates, not audited accounts presented by the company, and should not be treated as exact. They are still relevant to the support thesis: Transparent Edge appears to be a genuinely small specialist, not a hyperscaler wearing a local label.

What the customer is actually buying

The public service combines three distinct products that are easy to blur together.

The first is a shared public CDN. Transparent Edge says it delivers through more than 70 PoPs, uses Varnish Enterprise, charges the same per-gigabyte rate across geographies, and lets customers steer origins and destinations using request attributes. The next-generation CDN page presents this as the standard globally distributed service.

The second is a dedicated CDN. Here the customer receives dedicated servers in selected locations, managed by Transparent Edge. The company says a customer can combine dedicated nodes in important countries with shared delivery elsewhere, add code or databases at the edge, use a mid-tier origin shield and pay a traffic rate plus a fixed fee for each dedicated server. Dedicated hardware can improve isolation, cache persistence and capacity assurance, but the buyer still depends on Transparent Edge’s software, operating team, chosen facilities and network suppliers.

The third is a licensed CDN. Transparent Edge installs its Varnish-based software on servers controlled by the customer or another host, integrates those nodes into the service and manages the platform. Its licensed CDN description explicitly targets hosting companies, internet providers and organisations handling sensitive data. It says the customer can choose where hardware is located, keep data on exclusive servers, run code at the edge and combine the private network with Transparent Edge’s public CDN.

These are materially different sovereignty and exit propositions.

With the shared CDN, the buyer delegates location, capacity and much of the network to the provider. With dedicated nodes, the buyer gains isolation and can negotiate placement, but the service remains externally hosted and operated. With licensed nodes, the buyer can control the physical environment and potentially the network path, yet still relies on Transparent Edge for software maintenance, configuration and expertise.

The licensed design is the strongest answer to the question in this article’s title. A boutique provider does not need to own a hyperscale global estate if it can place a mature delivery engine inside customer-chosen infrastructure and supplement it with a shared network. That can turn sovereignty from a marketing adjective into an architectural property. It can also create a bespoke system whose portability depends on documentation, licence rights and staff knowledge.

Buyers should therefore stop asking “Do you have a sovereign CDN?” and ask “Which of these three deployment modes makes each data-flow promise true?” The answer for a public website may be shared delivery. A government API may require EU-only dedicated nodes. A broadcaster may want licensed nodes in its own facilities for domestic audiences and a second global CDN for international traffic. Transparent Edge’s flexibility is credible only when those choices appear in the service description, node inventory, routing policy and price.

A request crosses more than one cache

The onboarding documentation is unusually useful because it exposes the service mechanics.

The customer defines a public origin IP address or hostname, selects whether the origin connection uses TLS, sets the port and configures a health check. It proves control of the site by placing a tcdn.txt file at the origin or adding a _tcdn_challenge DNS record. The platform then generates initial VCL linking the hostname to the backend before the customer points DNS to its assigned Transparent Edge alias.

Once traffic arrives, Layer 1 servers terminate visitor TLS and serve cached content. Transparent Edge’s architecture documentation says these globally distributed servers serve “nearly 95% of Transparent Edge,” an imprecise phrase that presumably refers to eligible requests or traffic rather than the company itself. The same document describes an optional second cache layer—mid-tier or origin shield—that consolidates cache fills before they reach the customer’s origin.

The design has clear economic value. If thousands of outer-edge nodes or processes independently revalidate the same popular entity, the origin can receive a burst of duplicate requests. A mid-tier collapses those refreshes into a smaller number of upstream fetches. It also makes origin firewalling easier because fewer systems need access. The trade-off is another stateful layer: cache keys, expiry, stale-content rules, invalidation and observability must remain coherent across both tiers.

VCL is the policy language tying this together. A customer can vary cache behaviour by host, path, header, cookie, query string, geography and device; choose different origins; rewrite headers; set access rules; implement experiments; or protect specific routes. Transparent Edge says a configuration deployment is checked for syntax and usually takes two to seven minutes to propagate. The deployment history supports rollback.

That propagation window is operationally important. A two-minute global change is fast for planned work and long during a severe fault. Seven minutes can be short for a human approval process and very long when a bad rule blocks checkout traffic. A buyer needs to know whether changes roll through canaries, regions or the entire fleet; whether the platform automatically stops after error-rate changes; whether rollback requires the same propagation time; and whether emergency changes bypass ordinary controls.

The public documentation shows syntax validation, history and rollback. It does not show semantic testing against customer traffic, staged exposure, automatic health-based aborts or a published maximum configuration convergence time. Those may exist. They should be demonstrated, because configuration distribution is one of the largest shared failure domains in any programmable edge network.

Varnish is the engine and the dependency

Transparent Edge is refreshingly direct about Varnish. Its homepage says the platform is based on Varnish Enterprise. The deeper supplier case study goes much further.

In a Varnish Software publication, Transparent Edge’s chief technology officer says the company did not insert Varnish into a pre-existing CDN; it built the entire product around Varnish Enterprise. The case study says the whole CDN infrastructure uses VCL, that the service relies heavily on Enterprise capabilities beyond open-source Varnish Cache, and that the team “never considered” alternatives because of its prior experience. It also attributes “hundreds of thousands of customizations and changes” to the implementation and calls Varnish woven into the CDN’s DNA.

The publication is vendor-and-customer marketing, so performance claims in it are not independent benchmarks. The dependency description is nevertheless persuasive because it is specific, technically coherent and against neither party’s interest to understate the relationship.

Varnish gives Transparent Edge several real advantages. It is a mature HTTP cache with a specialised policy language. The Enterprise product adds vendor support and capabilities that a small operator would otherwise need to build and maintain. Transparent Edge can focus its engineering on multi-tenancy, security integrations, the dashboard, orchestration, billing, analytics and customer-specific policy instead of writing a cache engine from first principles.

The same choice creates concentration. A material Varnish licence change, product discontinuity, security defect, support dispute or incompatible upgrade would affect the platform’s core. The extensive customisation makes an alternative engine harder to adopt, even if VCL concepts can be translated. The more customer behaviour is encoded in provider-assisted VCL functions, the more migration becomes a software-reengineering project rather than a DNS change.

Transparent Edge’s self-service restrictions illustrate both prudent platform protection and this knowledge dependency. Customers may override only listed VCL functions. The portal does not allow Varnish’s return or call functions because misuse could threaten platform stability. Users cannot define arbitrary custom functions themselves, although Transparent Edge says its team can upload supported functions for them.

That is a reasonable multi-tenant control. It also means “programmable” does not mean unrestricted, and “open-source heritage” does not mean the deployed service is easily reproducible elsewhere. A buyer should classify every rule into one of three groups: portable standard VCL, Transparent Edge-specific functions, and externally integrated services. It should keep tests for each rule and require an export of the effective configuration—not merely the dashboard fields—so that exit work can begin before a crisis.

There is also a new competitive wrinkle. Varnish Software launched its own Europe-hosted managed CDN in 2026, promising that traffic, logs and data remain in Europe and using the same Varnish Enterprise engine. The upstream technology supplier is now also a potential substitute in Transparent Edge’s most differentiated market. That does not make conflict inevitable; vendors commonly serve partners and end customers. It does increase the importance of Transparent Edge’s own value: managed security, Spanish market knowledge, tailored engineering, global or customer-hosted deployment, and trust that does not come from the cache engine alone.

Seventy PoPs, one visible prefix, several meanings

Transparent Edge says it has more than 70 PoPs across more than 40 countries, including three in Spain. Its public list covers Europe, North and South America, Africa, the Middle East, Asia and Oceania. An older documentation page still says that the company had more than 50 PoPs as of November 2022, even though the page is marked as updated more recently. The difference is plausible growth, but the stale text shows why a marketing map is not an operational inventory.

Public BGP evidence presents a much smaller company-controlled view. AS214080, registered to Transparent Edge Services S.L. in October 2024, originates one IPv4 /24 and no IPv6 prefix. Hurricane Electric’s current view lists AS60068 DataCamp and AS29119 Aire Networks as its two observed upstreams and shows the prefix as RPKI-valid. BGP.tools similarly classifies the network as active content infrastructure operating in Spain.

This is not a contradiction. A CDN’s marketed PoP count need not equal the number of prefixes originated by its own autonomous system. The company can use supplier address space, host nodes behind another network, announce the same service through partners, or steer customers through DNS. The URLScan observation on AS60068 supports that explanation. AS60068 itself is a large carrier and CDN network, publicly visible with hundreds of originated IPv4 prefixes, many IPv6 prefixes and global transit relationships across multiple regions.

The distinction changes what “70 PoPs” proves.

At the weakest level, a PoP can mean an active service endpoint somewhere in a metro area. At a stronger level, it can mean reserved server capacity with local routing and tested failover. Stronger still, it can mean owned equipment, independent network paths, committed DDoS capacity, on-site support and audited data handling. Marketing counts usually combine sites without disclosing which level applies.

Transparent Edge’s public evidence independently supports the existence of an operating CDN namespace, a company ASN in Spain, upstream connectivity and service delivery through a substantial third-party network. It does not independently establish that Transparent Edge owns 70 physical clusters, has fixed dedicated capacity in each city, controls every routing decision, or can keep every request inside a selected legal region.

Procurement should therefore request a service-specific node schedule. For each relevant city, it should identify operator, facility country, address-space owner, equipment owner, cache persistence, IPv4 and IPv6 availability, normal and overflow routing, capacity commitment, DDoS path, support arrangement and whether the node is included in the contracted residency boundary. The provider need not reveal commercially sensitive rack coordinates. It does need to provide enough evidence for the buyer to understand the service it is buying.

Capacity deserves similar discipline. Transparent Edge says it can rapidly open nodes where required and that its network can handle attacks and traffic spikes. No public audited capacity figure, sustained throughput test, oversubscription policy or city-level headroom was found in the reviewed material. A buyer should not replace those missing numbers with the scale of AS60068; upstream network size is not the same as capacity contractually reserved for Transparent Edge or one customer.

IPv6 is a specific watchpoint. AS214080 has no originated IPv6 route in public views, while observed supplier infrastructure can support IPv6. The buyer should test the actual customer hostname from multiple regions over both address families. It should ask whether IPv6 traffic follows the same nodes, security controls, logging, rate limits and residency rules as IPv4 rather than inferring feature parity from a generic network statement.

Sovereignty has four locations

Transparent Edge says its technology is developed by a company with fully European capital and jurisdiction. Its sovereignty page goes further: traffic remains under sovereign control, data is not stored, shared or distributed and remains within the European Union, payloads are inspected only in volatile memory during TLS offload, personally identifying information is not logged in plaintext, and logs are managed according to customer instructions outside the reach of the US CLOUD Act. These are consequential company claims, not decorative branding.

The global PoP list complicates a literal reading. Cached entities served in the United States, Singapore, Japan or Australia are, in an ordinary technical sense, data stored and distributed outside the European Union, even if only temporarily. A visitor request terminated at such a node also crosses a non-EU processing location. The public page does not explain whether the EU-residency statement applies only to European configurations, only to customer account and log data, only to sensitive payloads, or to a newer product mode that excludes global nodes.

Four locations must be separated.

The first is the corporate and control location: where the contracting entity, support team, configuration service, account data and administrative access reside. Transparent Edge has a strong European case here because the disclosed company is Spanish and its support proposition is locally operated.

The second is the request-processing location: where TLS terminates, headers and bodies are inspected, WAF rules run and routing decisions occur. A global CDN necessarily processes requests near global users unless regional steering is constrained.

The third is the cache location: where response entities persist in memory or storage and for how long. Calling a cache “not storage” would not resolve residency obligations for many buyers; the material fact is that a copy exists on a machine in a jurisdiction.

The fourth is the log location: where raw delivery, security and administrative records are generated, buffered, retained, streamed, backed up and analysed. A customer may send logs to its own destination, but the edge node and delivery pipeline can hold data before that handoff.

The company’s licensed CDN can align all four locations if the customer supplies EU infrastructure, restricts routing and hosts log destinations appropriately. A dedicated regional CDN can also align them if the contract names the nodes and excludes overflow elsewhere. The shared global product cannot be assumed to do so merely because the vendor is European.

The right conclusion is unresolved scope, not a finding that the sovereignty claim is false. Transparent Edge may already support EU-only steering or segregated service modes. The public material does not establish the rule. Buyers should obtain a data-flow diagram and contractual node boundary for each hostname, plus a change-notification duty if the provider or a supplier adds a new location or subprocessor.

Logs are both evidence and personal data

Transparent Edge’s log delivery is one of its strongest operational features. The batch service sends compressed files every hour, with a file for each edge node that handled relevant requests. The filename includes the client identifier, country code and a node hash. Customers can send the files to FTP, SFTP or an S3-compatible destination, or use real-time streaming.

Streaming uses Kafka endpoints protected with certificates. The documented delivery format includes client IP address, requested path, browser identifier, referrer, country, cache result, response timing and security-related fields. Separate streams cover delivery, mid-tier, backend, WAF, bot mitigation and administrative activity. The streaming guide is practical evidence that buyers can integrate the service with a SIEM or analytics system.

It also makes a blanket statement that no personally identifying information is logged in plaintext difficult to apply without qualification. An IP address can be personal data under European law when it can be related to a person, and request URLs, referrers and browser identifiers can contain identifiers or sensitive parameters. The log format does not prove that every customer’s records contain personal data, but it shows that the system can collect fields with privacy significance.

This is not necessarily a defect. Security, abuse response, billing and performance analysis often require those fields. The issue is governance:

• Can the customer suppress, hash or truncate client addresses before they leave the node?
• Are query strings and selected headers excluded or redacted?
• How long does the edge buffer raw records before delivery?
• Does Transparent Edge retain a copy after successful transfer?
• Where do Kafka brokers, temporary files and backups run?
• Which staff and suppliers can access them?
• Can the customer choose an EU-only destination and prove that no duplicate stream goes elsewhere?
• Are WAF and bot logs governed by the same retention rules as delivery logs?

The customer also controls part of the location outcome. The documentation allows an arbitrary S3-compatible endpoint and illustrates a US-region Amazon S3 address. If a European customer chooses a non-European bucket, the CDN cannot by itself deliver EU-only log residency. Sovereignty is shared configuration, not a unilateral provider feature.

This makes Transparent Edge’s direct-engineer support potentially valuable. A named engineer can help design redaction, retention and field selection around the customer’s application. The contract should convert that help into stable configuration and documentation. Otherwise privacy compliance depends on remembered advice from one person rather than a repeatable service control.

Security is a chain of modes, not one shield

Transparent Edge combines network protection, request inspection, application rules, anomaly detection and manual emergency controls. The breadth is credible; the effectiveness remains workload-specific.

The company says Layer 3 and 4 DDoS protection is always on and that Layer 7 mitigation is available for web attacks. Its anti-DDoS page lists common floods and says VCL can block requests based on geography, headers, cookies and addresses. No public independently tested absorption capacity, attack report, scrubbing topology or service credit for mitigation failure was found. A buyer should therefore treat “always on” as a service design claim and test the contractual capacity and escalation behind it.

The WAF is integrated with Transparent Edge’s CDN but can also work with another CDN. The company says it protects sites and APIs, supports strict and detection-only modes, allows custom exceptions and rules, streams logs and charges by request rather than by the number of rules or sites. Its own WAF page advises using detection mode to identify false positives before blocking. That is sound implementation practice and a reminder that a WAF is not effective merely because a switch is enabled.

API protection needs two separate reviews. One concerns customer APIs passing through the edge: methods, paths, schemas, tokens, rate limits, body sizes, long-lived connections, client certificates and false positives. The other concerns Transparent Edge’s management API. The documented management API uses OAuth 2 client credentials, with keys obtained through the dashboard and bearer tokens for API requests to change or inspect the service.

The public documentation does not answer several control-plane questions: whether credentials can be scoped below company-wide read/write access, whether multi-factor approval applies to destructive changes, whether secrets rotate automatically, whether administrative network restrictions are available, and how quickly a compromised key can be revoked across the platform. These are procurement questions, not evidence of a weakness.

“Under attack” mode is an additional on-demand control, activated manually or through the API. It presents visitors with an interstitial while evaluating them and can be limited by country, network, address range, URL or domain. The documentation explicitly tells customers to turn it off when the danger has passed. That makes it a useful emergency mode, not a substitute for continuously tuned bot and DDoS controls.

An effective evaluation should replay representative traffic in detection mode, including mobile clients, API calls, accessibility tools, search crawlers, payment callbacks and unusual but valid requests. It should measure block accuracy and latency, then inject malformed and abusive patterns. It should also fail components deliberately: the anomaly system, log stream, management API, one edge region and the origin. Security controls that silently fail open or block healthy traffic during an unrelated outage can be as damaging as the attack they were intended to stop.

Post-quantum protection: real primitive, limited segment

Transparent Edge’s post-quantum claim rests on a real standard. NIST published FIPS 203 in August 2024, defining ML-KEM as a key-encapsulation mechanism believed to resist attacks by quantum computers under current knowledge. Hybrid TLS groups combine ML-KEM with established elliptic-curve key exchange so that a session remains protected if either component retains its security assumptions. The IETF has documented X25519MLKEM768 and related hybrid groups for TLS 1.3.

Transparent Edge says compatible browsers negotiate hybrid ML-KEM plus ECDHE to its edge by default, with no additional charge and no origin change. The key scope appears one sentence later: protection is applied between the visitor and Transparent Edge’s edge. If the edge then connects to an origin with classical key agreement, the full route is not post-quantum protected. The visitor-facing segment may resist harvest-now-decrypt-later collection while the origin segment does not.

That limitation does not make the feature meaningless. The public internet leg between a visitor and an edge endpoint is a plausible interception surface, and default client compatibility can improve coverage without application work. It means the claim should be described as browser-to-edge hybrid key agreement, not general post-quantum security for the application.

Authentication is another boundary. Hybrid key agreement protects how the session secret is established. It does not automatically replace the classical certificate signature used to authenticate the server. Nor does it protect data after TLS termination, at rest in cache, in logs, in the application database or in backups. Cloudflare’s detailed product matrix usefully separates post-quantum key agreement from post-quantum signatures and distinguishes visitor-to-edge, internal and edge-to-origin segments rather than using one platform-wide label. Transparent Edge buyers should request the same segment-by-segment statement.

The company’s page also says NIST set 2030 as the deadline for deprecating RSA and ECC. That compresses a more nuanced transition. NIST’s public project says quantum-vulnerable algorithms are to be deprecated and removed from standards under a transition extending to 2035, with higher-risk systems moving earlier. The underlying NIST transition publication was issued as an initial public draft and distinguishes algorithm types and security strengths across 2030 and 2035 milestones.

The practical procurement tests are straightforward. Measure what share of real clients negotiates the hybrid group. Confirm the exact group identifier and whether older clients fall back safely. Test packet fragmentation and middleboxes, because larger client handshakes can expose compatibility problems. Identify the edge-to-origin group separately. Ask whether TLS session tickets, key logs, certificates and administrative channels have their own migration plans. Then treat the feature as one useful control in a cryptographic inventory, not as evidence that the whole CDN is quantum-safe.

The origin remains the centre of failure

A CDN can hide an origin, reduce its load and serve stale content during some failures. It cannot make a poorly designed origin irrelevant.

Transparent Edge’s own error documentation is instructive. It maps several edge responses to origin conditions: the origin returns a server error; a network fetch fails; a health check marks the backend sick; a non-cacheable request fails; no backend is configured; or the requested entity is unavailable in cache. The platform can identify those states with specific diagnostic headers.

Cacheable public content has the best protection. If the entity is fresh—or the customer has configured acceptable stale serving—the edge can answer while the origin is unavailable. Personalised HTML, API writes, login, search, inventory and payment traffic often cannot be served safely from cache. Their continuity depends on origin health, application dependencies, database state and correct failover.

The mid-tier can reduce load but can also concentrate it. If an invalidation, configuration change or expiry causes many entities to miss at once, the shield may send a large refill wave to the origin. If the shield region fails, outer nodes may change their fetch path. If a customer puts Transparent Edge in front of CloudFront, a miss may traverse two CDNs before reaching the application, each with its own timeout, retry, cache and error semantics.

The AWS integration guide explicitly recommends this chain and claims savings of 35% to 45% in some scenarios by placing Transparent Edge before CloudFront or another AWS origin without changing the AWS platform. That percentage is a company claim dependent on traffic, cacheability, region and contract. The architecture can reduce CloudFront or S3 requests and origin egress. It can also make fault attribution and invalidation more complex.

A buyer should model at least five origin states: healthy, slow, partially failing, unreachable and returning corrupt but successful responses. It should test cache behaviour for each content class and HTTP method. Health checks should validate application readiness rather than only a generic 200 response. Multi-origin failover should prove that stateful requests do not jump to an inconsistent backend and that a failback does not create oscillation.

Origin security also changes after onboarding. The customer may firewall the origin to Transparent Edge address ranges, authenticate edge requests, use mutual TLS or secret headers, and remove public exposure. That is beneficial until an emergency migration requires another CDN or direct access. The exit design should maintain a tested break-glass path and keep origin capacity sufficient for the planned failover load.

Named engineers: differentiation and key-person risk

Transparent Edge repeatedly promises direct access to engineers, in Spanish or English, rather than a bot or anonymous queue. Its licensed CDN page says incident response is under fifteen minutes. Its homepage says the team can become part of the customer’s systems function and provide round-the-clock support when required.

For a buyer frustrated by hyperscale ticket systems, this can be a material advantage. Edge faults often cross DNS, TLS, caching, routing, security rules and application behaviour. A capable engineer who already knows the customer’s architecture can eliminate hours of triage and translate business urgency into a safe configuration change.

The commercial-database estimate of 11 to 25 employees also makes the proposition believable in one sense: a small customer may genuinely know the people operating the service. It creates a scaling question in another. A small team supporting a global network, security incidents, bespoke VCL, customer-hosted nodes and round-the-clock escalation must manage on-call coverage, holidays, simultaneous incidents and specialised knowledge carefully.

The promise should therefore be tested as an operating system, not as a relationship with one impressive engineer.

Buyers should ask how many people can safely change their configuration; how primary and backup contacts rotate; which response times apply to which support package; whether the fifteen-minute statement means acknowledgement, engineer engagement or mitigation; how many concurrent severe incidents the team can handle; and which suppliers must join an escalation. They should request anonymised response and resolution distributions rather than a best-case anecdote.

Documentation is the antidote to key-person risk. Every provider-assisted custom function should have a purpose, owner, test and rollback. Architecture decisions should be recorded in the customer’s own repository. Emergency changes should be reviewed after the incident. Access should belong to roles, not personal accounts. If the named engineer leaves, the customer should receive a structured handover and confirmation that another engineer has rehearsed the service.

This is where a boutique can outperform a hyperscaler. It cannot win by having more people. It can win by having fewer handoffs, better context and accountable ownership. The evidence should show that the intimacy scales beyond one person.

The simple gigabyte is only the first line of the bill

Transparent Edge’s headline CDN pricing is easy to understand: one rate per gigabyte transferred, the same regardless of geography, with no request charge. That can be attractive for applications with many small entities or APIs where request fees become material. It can also reduce the forecasting complexity created by regional bands.

The public site does not disclose the numerical gigabyte rate. The signup process asks customers to choose Advanced or Business support, provide a credit card and pay monthly for both the support package and consumption. The broader portfolio uses other billing units. WAF is billed by request. Dedicated CDN adds a fixed server fee. Edge transcoding is billed by time. Custom services, accelerated support and licensed deployments can add fixed or negotiated charges.

The proposition is therefore simpler than some competitors, but not a universal single-meter platform.

Public alternatives show why the details matter. Bunny’s standard network advertises region-based rates, including $0.01 per gigabyte in Europe and North America, and no request fees, while its volume network uses a lower global rate across fewer PoPs at high traffic levels. Fastly publicly prices both bandwidth and requests by region, with European delivery and request tiers visible on its pricing page. Amazon CloudFront offers pay-as-you-go pricing with data and request dimensions, but by 2026 also offers flat-rate plans bundling CDN, WAF, DDoS, DNS, logs, TLS, edge compute and storage allowances without overage charges.

Transparent Edge’s flat geographic rate can beat a hyperscaler for a particular mix without being the cheapest public CDN. A fair comparison must include:

• delivered bytes by region and protocol;
• billable requests for CDN, WAF and DDoS products;
• cache-fill and origin egress charges;
• purge, logging, certificate, DNS and edge-compute charges;
• support and professional services;
• committed minimums, burst treatment and attack traffic;
• dedicated node fees and unused reserved capacity;
• currency, tax, payment terms and annual price changes.

Attacks are especially important. A per-gigabyte contract can become expensive if malicious traffic is counted before mitigation. A request-priced WAF can become expensive during a Layer 7 flood. The customer should ask which blocked bytes and requests are billable at each stage, whether a spend cap can interrupt protection, and how disputed attack consumption is resolved.

The best pricing proof is a shadow bill. Feed at least three months of real logs into each vendor’s rate card, then replay a peak event and a representative attack. Transparent Edge should provide its own calculation, including support and origin effects. If the numerical rates remain confidential, the buyer can still contract the formula and verify it against monthly usage exports.

Second leg, front layer or true multi-CDN

Transparent Edge is most compelling when it is treated as a deliberate role in a broader delivery design.

As the primary CDN, it can provide personalised engineering, VCL control, WAF, DDoS mitigation and regional contracting. The customer retains a second provider for failover. As the secondary CDN, it can carry a defined percentage of traffic continuously, preserving warm caches and operational familiarity while limiting concentration. As a front layer, it can sit before CloudFront or another origin-facing service to improve cache logic or lower delivered cost. As a licensed platform, it can run inside customer-selected infrastructure and use a global CDN only for overflow.

Only the first two are naturally independent multi-CDN paths. A chain of Transparent Edge in front of CloudFront is not a second delivery leg for failure of the front layer: all visitors still depend on Transparent Edge DNS, TLS and configuration before reaching CloudFront. It may protect against an origin failure or reduce AWS cost, but it does not remove the outer provider as a single point of failure.

A true two-leg design needs neutral steering above both CDNs, usually through authoritative DNS, an independent traffic manager or application logic. Each CDN needs direct origin access, separate credentials, compatible certificates, independent health signals and enough capacity to take the other’s load. The origin must recognise both networks. Security policies must be equivalent enough that attackers cannot choose the weaker path.

Continuous traffic on the second leg is preferable to a cold standby. It reveals broken certificates, stale configuration, origin firewall drift and log-pipeline failure before an emergency. Even five percent of traffic can exercise the path, although the exact proportion should reflect cache economics and user impact.

Transparent Edge’s use of DataCamp/CDN77 infrastructure introduces another independence test. If the alternative CDN also depends on AS60068, the same facility estate, a shared DNS provider or a common upstream, the two logos may not represent two failure domains. The buyer should compare underlying networks, not merely vendors.

Configuration portability is the hardest part. Cache-control behaviour, VCL functions, bot decisions, header rewrites, origin selection and WAF exceptions rarely translate exactly between providers. The customer needs a canonical policy specification and automated behavioural tests that can run against both. The goal is not identical internals; it is equivalent business outcomes for critical routes.

Transparent Edge can be a credible second leg because it is programmable and supports direct engineering. Its smaller scale may even diversify a buyer away from the dominant US platforms. Credibility depends on keeping that leg operationally independent and proving the supplier chain beneath it.

Certifications are scoped evidence, not a platform aura

Transparent Edge says it holds ISO/IEC 27001:2022 and Spain’s National Security Scheme certification at the High category. Its site links the ISO badge to a TÜV Rheinland Certipedia identifier and the ENS badge to a direct certificate file in the official CCN governance system. The company announced the High ENS result in September 2025 and said its ISO certification, first obtained in 2013, had been updated to the 2022 standard in the same year.

The presence of direct third-party and government links is better evidence than an unlinked logo. On July 16, 2026, Certipedia redirected to a maintenance notice, and the linked ENS file did not render through the available public access path. The reviewed pages therefore did not expose the certificate scope, covered services and locations, issuing body details, validity dates, exclusions or statement of applicability.

That missing scope prevents two common shortcuts.

ISO 27001 certifies an information-security management system within a defined scope. It does not certify that every product is invulnerable, every PoP is owned by the certificate holder or every configuration is secure. ENS High similarly applies to named systems and services under specified conditions. It is not proof that any service a provider sells automatically inherits High status.

Spain’s own CCN guidance is explicit. A cloud provider’s High-category ENS certificate may cover only a subset of services, and compliance can depend on the customer selecting required items from a service catalogue. The guidance says buyers must pay close attention to scope because standards permit partial certification.

The company’s homepage also places “GDPR” beside ENS and ISO in a sentence saying the platform is certified. GDPR is a regulation with specific certification mechanisms, not a generic platform certificate equivalent to ISO 27001. Unless Transparent Edge can identify an approved certification scheme and certificate scope, buyers should read this as a compliance claim rather than a standalone GDPR certification.

Procurement should request the full current ISO and ENS certificates, scope statements, covered legal entity, sites, systems, service catalogue, auditor and expiry. It should map the purchased shared, dedicated or licensed deployment to that scope. It should ask how DataCamp/CDN77-hosted nodes, customer-hosted nodes, Kafka logging and support access are treated. If a node or supplier is outside scope, that may still be acceptable; it simply should not borrow the certificate’s authority.

The public information-security policy describes governance, risk management, continuity, supplier assessment, incident handling and security roles. It is evidence of a formal management approach. Operational proof requires audit reports, control evidence, incident exercises and service-specific mappings.

Outages can begin in four companies at once

No comprehensive public Transparent Edge status history or post-incident archive was found in the reviewed material. Absence of a public archive does not mean absence of incidents. It means an outside buyer cannot evaluate frequency, duration, communication speed or corrective-action quality from public records.

The likely failure domains can still be identified.

Transparent Edge can fail in its control plane, configuration service, certificate handling, WAF, cache software, logging pipeline or staff process. Varnish Software can introduce an engine defect or licensing disruption. A hosting or network supplier such as DataCamp can suffer routing, capacity, facility or DDoS problems. Aire Networks can affect the company’s own visible prefix. Customer DNS can misroute traffic. The customer origin can fail. A chained CloudFront service can add another control plane and cache.

These dependencies interact. A faulty VCL deployment can remove healthy nodes. A supplier routing event can make the platform think an origin is sick. A log outage can hide the evidence needed to tune the WAF. A certificate problem can make every healthy cache unreachable. A provider may mitigate an attack correctly while the customer origin collapses under allowed but uncacheable requests.

Rollback is necessary but not sufficient. A 2026 Gcore incident report, concerning a different CDN, describes how a malformed configuration combined with gaps in a configuration pipeline to cause a global service failure before rollback restored service. It is not evidence about Transparent Edge. It is a useful comparator showing why edge buyers should examine blast-radius controls and staged deployment, not merely the existence of a rollback button.

Transparent Edge should be asked for twelve months of service-level performance, severe incidents and maintenance affecting the contracted products. The buyer should see timestamps for detection, customer notice, engineer engagement, mitigation and final correction; impacted regions and services; whether logs remained available; and what changed afterward. Commercially sensitive customer information can be removed.

The service agreement should define which layer the availability commitment measures. DNS success, edge TCP acceptance, valid TLS, cache response and successful application response are different. A CDN can report edge availability while visitors receive origin errors. A WAF can be available while blocking valid users. The contract needs synthetic tests from agreed regions and an incident dispute process grounded in both provider and customer telemetry.

Competition comes from three directions

Transparent Edge does not compete with one homogeneous class of vendor.

The first group is hyperscale delivery and security platforms: Cloudflare, Amazon CloudFront, Akamai, Fastly and Azure Front Door. They offer vast networks, automation, broad integrations and mature public service operations. They can also create complex bills, ticket distance, platform coupling and jurisdictional concerns. CloudFront’s new bundled flat-rate plans weaken the argument that hyperscale pricing is necessarily unpredictable, while Fastly’s programmable edge competes directly on policy flexibility.

The second group is cost-focused CDNs such as Bunny and CDN77. Their public rates can be lower and their networks larger on visible measures. Bunny also advertises direct developer communication in enterprise support, so named expertise is not unique to Transparent Edge. CDN77 is particularly interesting because public observations place some Transparent Edge delivery on its parent network: a supplier can also be an economic substitute for customers willing to manage more themselves.

The third group is European sovereign or private delivery. Varnish CDN now sells a Europe-only managed service on the same core engine. Customer-operated Varnish, Nginx or cloud-native caches can keep control closer to the organisation. Telecom operators and hosting companies can deploy private or licensed edge nodes. These alternatives may have fewer global locations but stronger locality.

Transparent Edge’s defensible position lies between those groups. It can combine a European counterparty, global reach assembled through partners, Varnish depth, security products, customer-hosted deployment and human support. A customer need not choose it as a total replacement for a hyperscaler. It can use the company to create bargaining power, locality or operational diversity around the parts that matter.

That middle position is also vulnerable. If a customer only wants the cheapest gigabyte, public rate leaders are formidable. If it wants the largest independently visible attack surface and network, hyperscalers dominate. If it needs strict Europe-only routing with direct evidence, a geographically limited sovereign service may be easier to prove. If it has deep Varnish expertise, self-operation may reduce provider dependence.

Transparent Edge wins when the customer values tailored outcomes enough to pay for engineering, but still wants a managed service. The buyer should test whether the support and customisation actually reduce its total operating cost, rather than assuming intimacy is valuable on its own.

Switching cost begins before the first request

At first glance, CDN exit is simple: lower DNS time-to-live, configure a new provider and change the CNAME. The DNS documentation itself recommends lowering TTL before a move. That is only the visible cutover.

The durable switching cost accumulates in:

• VCL logic for caching, routing, experiments and security;
• provider-assisted custom functions unavailable in self-service;
• WAF rules, exceptions and bot decisions;
• origin firewall ranges, certificates and authentication;
• dashboards, API clients and deployment scripts;
• log formats, SIEM parsing and alert thresholds;
• dedicated or customer-hosted node arrangements;
• support knowledge about unusual application behaviour;
• commercial commitments and data-retention duties.

The exit path should be designed during onboarding.

The customer should retain authoritative DNS control and a tested ability to steer around Transparent Edge. It should keep origin certificates and capacity suitable for another provider. It should store configuration exports and behaviour tests outside the vendor dashboard. Every bespoke function should have a plain-language purpose and a fallback implementation. Logs should be continuously delivered to customer-controlled storage in a documented format.

For licensed CDN, the contract must say what happens to software, configuration and cached data at termination. Can nodes continue serving for a transition period? Does the customer receive a final configuration export? Who removes keys and certificates? What evidence confirms deletion? Can another operator reuse the hardware? Are Varnish Enterprise rights tied to Transparent Edge?

For dedicated CDN, buyers need node decommission timing, minimum terms and migration support. For shared CDN, they need cache purge and account deletion evidence. Across all modes, API credentials, TLS private keys, WAF data and logs require a revocation and retention schedule.

A practical migration rehearsal can be small. Route one low-risk hostname through an alternative CDN, reproduce the critical cache and security behaviour, and exercise failover twice a year. Measure not only availability but correctness: personalised content must not leak, purge must converge, APIs must preserve headers, and origin load must remain safe.

Transparent Edge’s advertised flexibility can reduce lock-in if the customer uses standard VCL, open log formats, external DNS and customer-controlled origins. The same flexibility can deepen lock-in if years of bespoke rules exist only in the provider’s team. Technology choice does not decide the outcome; operating discipline does.

The procurement tests that matter

A serious evaluation does not need to recreate a hyperscaler audit. It needs tests tied to Transparent Edge’s distinctive promises.

Identity and responsibility. Confirm Transparent Edge Services S.L. as the contracting, billing and data-processing entity. Obtain the current ownership statement, insurance, subprocessors and the division of responsibility among Transparent Edge, Varnish Software, DataCamp/CDN77, Aire Networks, facilities and any DNS supplier.

Node truth. Select the ten cities that matter most and require a dated node schedule. Run measurements from independent probes over IPv4 and IPv6, at normal and peak periods. Compare observed networks and countries with the contracted routing boundary. Do not require every marketing PoP to be owned; require every purchased promise to be evidenced.

Sovereignty. Use test hostnames with EU-only and global policies. Place unique cacheable entities and identifiable log events, then verify which nodes serve them and where records appear. Confirm that overflow, failover and DDoS mitigation do not silently change the permitted region. Map payload, cache, log, account and support access separately.

Cache correctness. Exercise cookies, query strings, authenticated responses, Vary, range requests, stale serving, purge by URL and tag, and two-layer invalidation. Confirm that private content is never shared between users and that a rollback restores the full prior behaviour.

Origin protection. Measure origin request reduction, then simulate cold cache, mass expiry and one mid-tier failure. Verify rate limits, retry behaviour, health-check accuracy and multi-origin consistency. Confirm that origin firewall rules can accommodate a second CDN without an emergency policy rewrite.

Security efficacy. Start WAF in detection mode, replay representative valid traffic and known attack classes, and measure false decisions and added latency. Test Layer 7 floods, non-cacheable endpoints, WebSockets or streaming where relevant, and the transition into and out of under-attack mode. Require the provider to state committed mitigation capacity and billing treatment.

Control-plane safety. Review roles, multi-factor authentication, API scopes, secret rotation, approval for high-impact changes, audit records and emergency revocation. Deploy a harmless bad configuration in a test service and observe validation, propagation, automatic alarms and rollback time.

Operational support. Trigger incidents during and outside business hours. Record acknowledgement, engineer engagement, diagnosis quality and supplier escalation. Meet the secondary engineers, not only the sales engineer. Inspect handover and change-review practices.

Cost. Replay real usage against the complete rate formula, including support, WAF requests, attack traffic, logs, dedicated capacity and origin egress. Compare a normal month, a peak event, a low-cache month and an attack month. Contract the units, exclusions and price-change mechanism.

Exit. Before full launch, migrate a test hostname away. Confirm configuration export, log continuity, certificate replacement, cache deletion and origin readiness. Price the provider’s transition support and define a maximum assistance period.

Passing these tests would provide much stronger evidence than a logo wall or a generic reference customer. Failure does not always disqualify the provider; it reveals which risk needs architecture, contract or price adjustment.

What remains unproven

Several important claims could not be independently established from public material.

The complete 70-plus PoP inventory, its ownership mix and city-level capacity remain company claims. Public routing and DNS observations validate pieces of the service, not the full map. No independently audited performance distribution, cache-hit rate, attack capacity or customer-wide uptime figure was found.

The exact scope and current validity details of ISO 27001 and ENS High could not be read from the linked certificate files during access. The badges and direct registry links support that certificates exist, but product, location and supplier coverage requires the documents themselves.

The EU-residency statement is not reconciled publicly with the global shared-CDN map. The treatment of cached entities, temporary buffers, security logs and non-EU nodes remains a contractual question. The exact list of subprocessors and infrastructure suppliers by region was not found in the reviewed public pages.

The company’s customer stories and claim of serving thousands of websites may indicate meaningful operating experience, but they do not establish performance for a new workload. One official public-sector award does show that the company has won a concrete Spanish contract: in June 2025 the parliament of Asturias awarded Transparent Edge a one-year CDN, DDoS-control and web-filtering service for €14,834.58 including tax. It was the only bidder, so the award validates procurement and price at that scope, not competitive superiority or service performance.

No public incident chronology was found that would let a buyer assess transparency after failures. No public numerical shared-CDN rate was found. No independently verified staffing, on-call capacity or fifteen-minute response distribution was available.

These gaps are not unusual for a private specialist. They matter more here because Transparent Edge differentiates itself through transparency, sovereignty and human support. The company can turn gaps into an advantage by answering them more directly than a hyperscaler would.

The verdict: credible when bought as a defined leg

Transparent Edge is a real Spanish edge provider with a coherent technical proposition, not merely a reseller label. The 2021 merger joined a systems company with a CDN and a security business. The service has a documented onboarding flow, programmable cache architecture, security controls, API, log delivery, dedicated and customer-hosted options. Public DNS and routing evidence show an active network assembled partly through major infrastructure partners. Varnish Enterprise provides a mature engine and a significant supplier dependency.

The company can credibly substitute for a hyperscale CDN in workloads where buyer priorities align with its strengths: European contracting, direct engineering, VCL customisation, a simple standard-CDN traffic meter, Spanish public-sector familiarity, and the ability to deploy dedicated or licensed nodes. It can be especially valuable as a second leg that keeps policy and bargaining power outside one US platform.

It is less credible as an unqualified global sovereign replacement based only on the public website. The full PoP count, node control, capacity and residency boundary are not independently visible. A global cache network and an EU-only data statement require a product-specific explanation. Certification scope needs the actual certificates. Named support needs evidence that it survives scale and personnel changes.

The decisive insight is that sovereignty can ride on someone else’s network, but only if control is specified. A Spanish company can operate software on leased global infrastructure while preserving European governance for some data and services. It can also lose that property through non-EU caches, supplier access, logging or failover. Corporate nationality is the beginning of the answer, not the end.

Transparent Edge should therefore be bought as a defined leg: named deployment mode, named regions, named suppliers, named support obligations, measurable capacity, portable policy and a tested exit. Under those conditions, boutique scale can be a feature. Without them, the second CNAME carries more of the truth than the sovereignty slogan.