ENISA portal protection
architecture and two clear alternatives

01Goal and principle

We protect the ENISA portal from attacks. You keep your servers and your application; we sit in front and filter attacks.

02Build CDN-first — protect only what is truly dynamic

The single most effective step: put as much of the site on the CDN as possible, so active protection only covers the small dynamic part.

Static content — pages, images, styles, scripts, documents — is cached at our edge, close to visitors, and served without touching your origin. A flood against a cached page is absorbed at the edge. Only truly dynamic and sensitive requests (login, account actions, data submission) need the active protection in this document.

03Traffic planes and three zones

We split the site so that as little as possible — and as controlled as possible — reaches the sensitive part.

04Control layers — anycast POP and dedicated box

Every point has several layers. On the dedicated box, one shared table holds state across the whole box; a fast store (Redis) distributes it to other boxes and up to the edge.

05What happens to a request

Depending on the content type and the visitor state (unknown / OK / KO), a request goes to a different place. Switch the scenario to see the path. The sensitive case is where the two alternatives differ (Part II).

06Profile and signals

The profile has two levels. A rich profile decides on the box (where we terminate). A thin key propagates down so the edge can evaluate OK/KO.

07Propagation, latency and failure

State is written only by the terminating layer. The edge only reads. The hot path always reads locally; the times below are for replication only.

08Topology and failover — we recommend 3+ locations

We balance traffic across all dedicated locations (active/active). A failure of one means reduced capacity, not an outage.

09Multi-layer limits and rules

On every layer we can limit or block counts and rates. Each counter applies per any dimension, over any time window, and settings can differ per value.

Examples: "max 100 requests per 10 seconds per IP on /api/submit"; "max 5 new connections per second per datacenter IP"; "challenge a country's VPN ranges on the login path"; "rate-limit per ASN per hour worldwide, except an allow-listed partner network."

10Challenges — CAPTCHA and Proof-of-Work

Yes, we have CAPTCHA — and several types of Proof-of-Work. Our approach is invisible-first, so genuine users rarely see a challenge. We tune the trigger, difficulty and type per site and per path.

https://portal.enisa.europa.eu/  ·  security check

Quick security check

WEDOS Global Protection · verifying your connection

We are making sure you are a real visitor. For most people this happens automatically, in the background, and needs no action. Only when something looks unusual do we show a short check.

Level 1 · invisible check — passed

Level 2 · proof-of-work (runs quietly)

Level 3 · CAPTCHA (only if still needed)

I am a person

Difficulty scales with risk. Most visitors never see levels 2 or 3. We tune which level applies, per site and per path. Available in all 24 official EU languages.

Figure — Challenge design: invisible-first, then Proof-of-Work, then CAPTCHA only if needed. Included in the service, tuned to your needs.

11Block page (from CDN cache)

The page a blocked visitor sees: an explanation, contact, and a copyable request summary. It is fully cached in the CDN, so attacking it costs no origin resources. Available in all official EU languages.

https://portal.enisa.europa.eu/  ·  HTTP 429

Access temporarily restricted

Request blocked by WEDOS Global Protection

This request was temporarily blocked by attack protection. If you are an authorized user, please try again shortly, or sign in. If the problem persists, contact support and include the request summary below.

Request summary (copy for support)Copy

Ref:    a1b2c3d4-ee55-46f7-9a01-d3f2c7b18e90
Time:   2026-06-28 09:41:07 UTC
Reason: rate-limit / reputation
Node:   edge-anycast (LU)

Contact: soc@enisa.europa.eu  ·  wedos.com

BGESCSDADEETELENFRGAHRITLVLTHUMTNLPLPTROSKSLFISV

Available in all 24 official EU languages. The page is fully cached in the CDN — attacking it requires no origin resources.

Fig. 5 — Example block page served from CDN cache (WEDOS + ENISA logos, explanation, contact, copyable request summary, language selection).

12The two alternatives at a glance

For the sensitive flow there are two alternatives. Both share one promise: we cannot read your content. They differ in how much L7 protection we can give and how much you change in your app.

13L7 protection without seeing content (pass-through)

We give full protection where it is safe to look, and we deliberately do not decrypt the sensitive zone. This needs no change in your application.

For the sensitive zone we do not hold the keys and do not see the content. We decide using signals that do not need the content: the source (IP, ASN, country), the fingerprint learned at login, the request rate and size, and the trusted/blocked/unknown state carried from the login zone. Known-bad and over-limit traffic is stopped near the visitor; only good traffic reaches your origin, which decrypts and authorizes.

What happens to a request here

1. Arrive. The visitor reaches the nearest edge location (anycast).
2. Sort. We classify the visitor as trusted, unknown, or blocked — from signals that do not need the content.
3. Serve or check. Static parts come straight from the CDN cache; the login zone is terminated, with bot detection and a challenge only if the visitor looks risky.
4. Pass through. For the sensitive zone we do not decrypt. Known-bad and over-limit traffic is stopped first; the rest is forwarded to your origin, still sealed.
5. Open at your origin. Your server decrypts and authorizes. We never saw the content.

Termination vs pass-through — where the lock opens

The point where the lock opens is where we can see content. In this alternative, for the sensitive zone it opens only at your origin.

14L7 protection with sealed content (E2EE / HPKE)

Here we do terminate the sensitive flow and give it full L7 protection — yet still cannot read it, because the content is sealed end-to-end with a key we never hold.

In plain terms: your website locks the sensitive content in a box before it leaves the visitor. We guard that box the whole way — but we never hold the key. Only your own server can open it.

How it works, in plain words

It works like a second layer of HTTPS, carried all the way to the ENISA origin. Your origin publishes its public key. We only deliver that key to the browser — without the matching private key it is useless to us. The browser uses it to protect the content, sends it through us encrypted, and only your origin can open it. We see the ciphertext and the metadata, never the content.

Forward secrecy. The browser makes a fresh one-time (ephemeral) key for every message, sends its public part in the envelope, and discards the private part. Even if a key were compromised later, past messages still cannot be decrypted.

Tamper-evidence — the bonus. This does not come from the encryption alone; it comes from authenticated encryption (AES-GCM), which attaches a cryptographic tag to every message. If anyone, including us, changes a single bit of the envelope, decryption at your origin fails and the message is rejected. The envelope header (method, path, time, request id) is bound into that tag too, so a sealed body cannot even be replayed to a different endpoint. The “Simulate tampering” toggle in the demo shows exactly this.

How it works — in four steps

The technical version: the client (a browser script or a machine client) wraps only the body of the request in a sealed envelope (using HPKE, RFC 9180) addressed to your server's public key. Only the payload is sealed — structure, headers, sizes and fingerprint stay visible, so we apply rate-limiting, bot detection, challenges and a structural firewall before your origin. Your origin unseals it with its private key (in an HSM). We do not use nested TLS — only the payload is sealed.

What happens to a request here

1. Seal. The visitor's app wraps the request body in a sealed envelope (HPKE) addressed to your origin's public key.
2. Arrive. It reaches the nearest edge over HTTP/2, sealed the whole way.
3. Guard. We terminate the outer connection and apply full L7 — rate limits, bot checks, a challenge if needed, and a structural firewall — reading only the outside (headers, size, fingerprint).
4. Forward. We pass the still-sealed body to your origin.
5. Unseal. Your origin opens it with its key (HSM), checks the client is authorized, processes it, and seals the reply.

14.1  For people and for machines

The same sealed-envelope format is used by everyone; only how the client obtains its key differs. Confidentiality to the server needs no client key. Proving "authorized only" uses a client key, or a password-based method (OPAQUE) for people.

14.2  Can you just add an encryption JavaScript to the browser?

Yes — a small drop-in JavaScript SDK. But it always needs a matching piece at your origin, because the data must be decrypted somewhere to be used. There is no browser-only version. With a CDN-first site, only a few dynamic endpoints need sealing, so the integration is small.

1. Client: add one <script> tag and a short config (which endpoints to seal, your server's public key). The SDK seals request bodies and unseals responses transparently.
2. Server: add a small decrypt/encrypt step on those endpoints, with your private key in an HSM.
3. Delivery integrity: serve the SDK and the page that loads it via pass-through or your own origin, and pin the file hash with SRI.
4. Identity: register client keys (machines) or use OPAQUE (people).

14.3  The one real weakness — delivery of the crypto code

In the browser, E2EE is only as strong as the integrity of the code that encrypts. Whoever serves the page could substitute crypto that leaks the key. Because we terminate the outer connection, we are structurally in that position — so the guarantee against us is only as strong as the code delivery.

14.4  Deployment effort and CRA

Effort: low-to-moderate and phased. You add the SDK on a few endpoints, a decrypt step at the origin, a server keypair (HSM), and choose the identity model. Alternative 1 needs zero app change and can start now; Alternative 2 is added later on the endpoints that need it.

15What we see outside the envelope

A clear line for the record: in both alternatives we never see the content. Everything else is operational metadata. This is what “we protect it but cannot read it” means in practice.

The design rule that follows: sensitive data goes only inside the sealed body — never in the URL, headers, or cookies, because those are visible to us in Alternative 2.

Alternative 1 hides more — we do not terminate, so method, path and headers stay inside TLS — but gives only network-level protection on the sensitive flow. Alternative 2 exposes the request envelope and headers to us so we can apply full L7, yet the body stays sealed.

What can be inferred without reading the content

Even sealed, some things leak from the shape of traffic: the message length (ciphertext ≈ plaintext + 16 bytes), timing and frequency, which endpoint was called (a path like /api/delete reveals intent), and per-user correlation via IP, fingerprint, cookie or request id.

16Choosing between them

You do not have to choose forever now — the two can coexist.

17Full configuration list — everything we can do

Everything below is configurable per site and can be combined. You do not need to learn this — we set it up and tune it for you.

16.1  Signals we can decide on

16.2  Limits — per dimension, per time window

Connections, requests, and requests per URL — over 1 s / 10 s / 1 min / 1 h or a custom window — per IP, prefix, ASN, country, continent, IP category, URL/path, browser, or fingerprint, and in any combination. IP categories are open-ended, and per-IP settings can differ.

16.3  Actions

16.4  Other controls

18Appendix — Due diligence (summary)

19Versions