Cloudflare security and edge services
Review and improve Cloudflare DNS, TLS, WAF, access and edge configuration with controlled rollout, evidence and a practical rollback path.
What we review
- DNS and domain security: Zone inventory, delegation, DNSSEC, record accuracy, certificate authority authorization, email-related DNS, access control and migration planning.
- Application security and delivery: Proxy status, SSL/TLS modes, origin protection, managed and custom WAF rules, rate limiting, bot controls, redirects, caching and response security headers.
- Zero Trust access: Access applications, identity provider integration, device posture, service tokens, private network access, policy order and administrator recovery.
- Cloudflare Tunnel and network connectivity: Connector placement, routing, redundancy, origin reachability, outbound dependencies, private DNS, monitoring and failure behaviour.
- Workers and edge applications: Routes, bindings, secrets, environment separation, deployment controls, observability, caching behaviour and rollback.
- Account and administrative controls: Account structure, roles, multifactor authentication, API tokens, audit logs, emergency access, ownership and supplier boundaries.
- Migration and change review: Current-state inventory, destination configuration, staged activation, validation from multiple paths and a realistic recovery plan.
Deliverables
- Account and service inventory: Zones, applications, tunnels, Workers, identity connections, account roles, relevant plan limits and known external dependencies.
- Configuration and risk findings: Evidence, affected resource identifiers, service impact, priority, recommendation and any uncertainty caused by unavailable access or telemetry.
- Target architecture: Traffic, identity, DNS and administrative paths, including origin controls and expected behaviour when an edge or connector component fails.
- Migration or change runbook: Prerequisites, ordered steps, propagation considerations, service tests, monitoring, hold points and rollback limits.
- Candidate configuration: Where included, proposed policies or settings ready for review before production activation.
- Validation and handoff record: Observed results, configuration deviations, remaining actions, ownership and the evidence operators should retain.
Engagement boundaries
- Cloudflare is one part of the service. The engagement distinguishes Cloudflare controls from registrar, identity, origin, application, carrier and internal network responsibilities.
- Included: Review or design of the named Cloudflare accounts, zones and products.
- Included: Checks against the plan, permissions and configuration visible during the engagement.
- Included: Coordination requirements for registrar, origin, identity and network owners.
- Included: Validation and rollback planning proportionate to the proposed change.
- Not included: Cloudflare licensing, resale, contractual advice or a commitment that a feature will be available on a given plan.
- Not included: Replacement for Cloudflare Support or access to provider-internal systems.
- Not included: Application code remediation, origin redesign or identity-provider changes unless specifically scoped.
- Not included: A promise that WAF, bot or rate-limiting controls will stop every malicious request or avoid every false positive.
- Not included: Immediate DNS rollback where resolver or negative caching controls propagation outside the organization.
Questions before the work starts
Can you review an existing Cloudflare configuration without changing it?
Yes. A read-only review can examine the agreed account, zone and product settings and compare them with observed service behaviour. Findings will state where origin, registrar or identity evidence is also required.
Can you help migrate DNS to Cloudflare?
Yes. The work can include source-zone inventory, destination-zone validation, DNSSEC and registrar planning, critical record checks, delegation monitoring and recovery steps. The old zone should normally remain intact until the new delegation is stable.
Will WAF rules be deployed directly to production?
Only when implementation is in scope and the organization has approved the change. Candidate rules are reviewed against available traffic first. Staging, logging or managed-rule action controls may be used where the product supports them.
Can the engagement cover both Cloudflare and the origin environment?
Yes. The origin portion must be named in scope and supported by appropriate access. This is often useful for TLS mode, source-address handling, origin allowlisting, caching, health checks and incident troubleshooting.
Do you work only with Cloudflare Enterprise accounts?
No. The engagement is based on the account and plan in use. Recommendations distinguish available controls from features that would require a plan or product change, and they do not assume an upgrade will be purchased.
Can every Cloudflare change be rolled back immediately?
No. Many configuration changes can be reverted quickly, but DNS caches, certificate issuance, cached content, connector state and external identity sessions may outlive the change. The runbook identifies those limits before implementation.
The platforms this work covers
Edge work centres on Cloudflare, with the origin-side and application-delivery layer reviewed alongside it.
- Cloudflare DNS, WAF, Access and Zero Trust
- F5 application delivery and WAF
- Azure and AWS origins behind the edge
- Microsoft 365 mail flow and domain authentication
Audits available
- Cloudflare configuration audit: DNS, TLS, WAF rules, Access policies and origin exposure.
- Public edge exposure audit: what reaches the origin directly and what is genuinely filtered.
Other ways we can help
Engagements are often scoped together; these are the closest neighbours to this one.
Planning a Cloudflare migration, review or security change?
Share the products involved, the current service path and the outcome you need. Include any registrar, origin, identity or network dependencies already known.