Security projects often begin with a false choice: replace the current CDN or accept the controls it already provides.
Real environments are messier. A business may have a long-term CDN contract, cloud-specific routing, established cache rules, a migration freeze, or applications that cannot all move together. The security problem still exists. Residential proxy traffic, credential stuffing, scraping, API abuse, and Layer 7 floods do not wait for a platform consolidation programme.
Peakhour Bring Your Own Edge supports two first-class paths: Peakhour Edge can be the delivery layer, or Peakhour intelligence can operate alongside the edge provider already in place. The product value is not the diagram. It is retaining one decision model for request context, policy, action, and evidence in either deployment.
Decide Where the Authoritative Observation Happens
An application behind a CDN sees a connection from the CDN, not necessarily the original client-facing connection. That affects IP provenance, TLS fingerprints, geography, and rate counters.
Before adding another control, map the path:
client → existing edge → Peakhour decision point → origin
or:
client → Peakhour Edge → origin
For every field used by policy, record where it was observed and who is allowed to set it. Client-supplied copies of forwarding or fingerprint headers must be removed at the trusted boundary. The authoritative edge can then set the value passed downstream.
This is not bookkeeping. A rate limit built on a spoofable forwarded address is a client-controlled rate limit. A TLS fingerprint calculated at origin may describe the intermediary rather than the browser. Provenance determines whether the signal can safely change an action.
Keep Policy Close to the Consequence
A decision point earns its place only if it can still protect the route. It needs to prevent avoidable origin work, slow repeated behaviour, challenge an interactive browser, block a confirmed attack, or preserve a clean path during a flood.
Peakhour combines IP intelligence, residential proxy detection, fingerprints, credentials, route behaviour, bot state, rate thresholds, and WAAP findings in that request path. The action can be allow, log, challenge, rate limit, or block. The existing CDN can remain responsible for the delivery work it already does well.
This matters because enrichment without enforcement creates a timing and ownership gap. A lookup result delivered after the application has rendered a page, queried a database, or changed account state may still help an investigation. It did not protect that request.
Network intelligence is useful on account creation, login, and password-reset routes when the signal remains connected to the request. Peakhour carries that context through to route-specific action and retains the outcome.
Migrate a Decision, Not the Whole Estate
A staged deployment can begin with one abused route:
- Observe the request at the trusted boundary.
- Forward or derive the fields required by the policy.
- Run the new decision in monitor mode.
- Compare it with current CDN and origin outcomes.
- Apply one reversible action.
- Expand only after false positives and operational ownership are understood.
Login, account creation, search, scraping targets, and expensive API operations are good candidates because their behaviour is measurable and their business consequence is clear.
Duplicating every rule in two systems is not a migration strategy. Decide which layer owns each action, how conflicts are resolved, and which record is authoritative. A request should not be challenged twice because two providers reached the same conclusion independently.
Preserve Cache and Origin Context
Bot and proxy decisions affect more than authentication. Scrapers and Layer 7 floods consume cache, transformation, application, and origin capacity.
A useful decision record can include:
- cache status and whether the request reached origin;
- route and request cost class;
- proxy, IP, fingerprint, credential, and bot evidence;
- rate-limit state and selected action;
- response status and origin health;
- policy revision and enforcement point.
That joined record shows whether a control actually protected capacity. Blocking more requests is not inherently better. Serving clean cache hits while throttling expensive automated misses may produce a stronger outcome than a broad deny rule.
Make the Trust Boundary Explainable
NIST's Zero Trust Architecture frames access around explicit resource decisions rather than implicit trust in network location. The same discipline helps at an application edge: evaluate the request from current evidence, enforce a resource-specific policy, and retain enough information to explain the decision.
An existing CDN is not an obstacle to that model. An undefined trust boundary is.
Use the delivery reality you have. Identify the client-facing observation point, choose the routes where better context can change an outcome, and assign policy ownership. Move delivery layers when the operational case supports it—not because a security feature forced an all-or-nothing migration.
