DNS filtering and site controls need consistent cloud policies

DNS filtering and site controls add early cloud checkpoints

DNS filtering and site controls give security teams earlier opportunities to stop unsafe access in 2026. Domain Name System (DNS) filtering checks the domain names devices request, while site controls govern the destinations users can reach through browsers or managed devices. Both add checkpoints to a layered security architecture. Their effectiveness depends on consistent enforcement across working locations and coordination with account protection, access permissions and defenses against software vulnerabilities.

These checkpoints matter because software-as-a-service (SaaS) platforms, remote access tools and AI-powered services connect users and workloads across distributed environments. The connections expand what organisations can do, but they also give harmful activity more ways to reach business systems. Security models built for contained, on-premises operations struggle with this traffic’s volume and speed. As services and working locations change, a fixed boundary becomes harder to maintain.

Distributed teams and remote or hybrid organisations face another difficulty when their security tools work separately. Some have added DNS filtering and site controls to their existing defenses to reduce exposure. To make these additions useful, teams need to enforce destination rules consistently as activity moves while preserving protections against other routes of initial access.

Entry routes and fragmented tools require different responses

To place destination controls correctly, security teams first need to understand how attackers enter cloud environments. Google Cloud’s Mandiant team attributes 83% of initial entries into major cloud and SaaS environments in its incident data to identity and access issues. Google Cloud benefits commercially from demand for cloud security, giving it a stake in how organisations respond. Mandiant’s finding puts account protection and access permissions at the centre of decisions about those incidents.

Credential abuse also features in Cloudflare’s analysis of trillions of network signals. Cloudflare, which sells security services and benefits from spending on protection, describes attackers entering through compromised credentials alongside increased targeting of SaaS environments and supply chains. A valid account can let an attacker in without breaching a conventional network boundary. Destination restrictions can interrupt some related activity, while identity controls address whether the account itself should be trusted.

Software exploitation requires a separate response. Verizon, which has a commercial stake in security services, says in its latest breach report that exploitation of software vulnerabilities overtook stolen credentials as the leading entry point for “the first time in nearly twenty years”. Verizon’s finding and Mandiant’s percentage point to the need to address both entry routes. Vulnerability management addresses exploitable software weaknesses, while identity and access management governs account use and permissions.

The response window for software weaknesses can be short because active exploitation may follow disclosure within days. Attackers continually probe systems where delivery speed and convenience have taken precedence over security. Misconfigurations can expose services, and excessive permissions can give an account access to more resources than its work requires. Shadow IT, tools and services adopted without organisational approval, adds activity that security teams may struggle to see or govern.

These weaknesses can also intersect with unsafe destination choices. An analysis titled “10 real-life cloud security failures” groups most of its ten failures around misconfigurations, overly broad access or users reaching unsafe destinations. Each category points to a different operational responsibility: configuring services, setting permissions or controlling access to destinations. Separating the categories helps teams assign the right protection to each failure.

The scale and cost of cloud incidents make these responsibilities a business concern. SentinelOne, a security vendor that benefits from demand for cloud protection, reports a 21% year-over-year increase in cloud infrastructure attacks and says roughly 45% of data breaches occur directly inside cloud environments. It presents cloud exposure as a cross-industry issue and reports an average cost of $5.17 million per incident. For organisations that depend on remotely accessed services, the consequences affect technology budgets and day-to-day operations.

Responding becomes harder when protection tools work in isolation. The Fortinet 2026 Cloud Security Report describes a “complexity gap,” with nearly 69% of organisations identifying disconnected tools, visibility blind spots and inconsistent controls as their biggest difficulties. Fortinet sells security products and services, so it benefits commercially from demand to address these problems. The reported difficulties explain how organisations can own substantial security technology yet struggle to apply policies reliably.

A policy can fail when separate systems interpret or enforce it differently. Incomplete views of activity also make it harder for teams to track changes in services, users and workloads. Remote and hybrid work adds inconsistency when a rule depends on where someone connects. Destination controls therefore need a clear purpose and a dependable way to apply decisions across working environments.

DNS filtering and site controls interrupt access at different stages

The first checkpoint is the domain lookup. DNS translates a domain name into the addressing information a device needs to reach its destination. DNS filtering checks that lookup and can prevent a dangerous domain from resolving. Blocking the lookup interrupts the request before a full connection forms.

Site controls add a decision when a user tries to reach a destination through a browser or managed device. The organisation’s site policy determines whether the user can access it. DNS filtering and site controls therefore intervene at different stages while supporting a common access rule. Together, they can reduce the set of harmful destinations users can reach.

Reducing that set can prevent interactions with phishing pages, malware-related sites and other unsafe destinations. It also reduces the attack surface: the systems, services and destinations through which harmful activity could occur. Domain- and site-level blocking may interrupt some credential-led attacks by stopping access to a destination involved in the attack. Account protection and permission controls continue to govern trust in the identity and the resources it can use.

Teams that have added these controls report lower exposure to phishing and malware, along with better visibility into unsanctioned tools and risky browsing. Better visibility helps security teams spot differences between actual and approved service use. Teams can examine these reported changes in their own environments. Tracking exposure and visibility gives the deployment a practical purpose tied to how the controls work.

The deployment must also preserve access to services employees need. Teams report blocking unsafe access earlier while maintaining the speed of authorised activity and working alongside existing cloud-native systems. Achieving that balance depends on policies that distinguish risky destinations from those required for legitimate work. Engineering and infrastructure leaders therefore need to consider usability when deciding how to apply destination restrictions.

Threat intelligence, information used to identify malicious activity, helps inform those decisions at scale. Cisco, which sells Cisco Umbrella and benefits commercially from demand for DNS security, says the service uses global threat intelligence and blocks “millions of malicious domains daily” across a large volume of DNS requests. Umbrella illustrates how intelligence-supported domain blocking can operate across substantial traffic. For a deployment team, the operational question is how that intelligence informs the rules applied to its own users and workloads.

Integration determines whether added controls reduce fragmentation

Applying these rules creates a tension: destination controls add enforcement points, but they can also add systems to manage. Separately administered DNS and site-control products create more places to maintain rules and inspect activity. Their architectural value therefore depends on how their decisions connect to the wider security environment. Isolated rules and separate handling can increase the coordination work teams already face.

Security Service Edge offers one way to organise this integration by bringing security services for access to cloud and web resources into a shared architectural approach. DNS and site decisions can then support a broader access policy. A zero-trust architecture evaluates access requests without assuming that a user or device is safe because of its location. The approaches address different architectural concerns, but both can support policies that remain applicable as users and workloads move.

For remote and hybrid workers, that continuity means staying subject to the organisation’s destination rules when their working location changes. Enforcement must follow the activity for the policy to remain dependable. Requiring users to stay within one physical or network location would preserve the mismatch between distributed work and location-dependent protection. Integration needs to make the rule portable across the access contexts the organisation uses.

Zero trust also establishes how that rule contributes to a wider access decision. Its principle of evaluating “Every request” makes each request subject to the relevant policy rather than carrying forward an assumption of trust. DNS and site controls contribute destination decisions, while identity systems assess the account and permission controls determine what it may do. Vulnerability defenses retain responsibility for exploitable software weaknesses.

Keeping these responsibilities clear also helps teams use threat intelligence consistently. Information about malicious destinations can support earlier blocking across users and workloads when the resulting decisions feed into the same operating approach. Account protection, appropriate permissions and timely treatment of vulnerable software remain necessary alongside that blocking. Integration must preserve these separate functions while making their policies easier to apply together.

Teams using DNS filtering and site controls report more consistent enforcement and reduced dependence on fragmented point solutions. Whether an addition delivers those benefits depends on how it changes everyday policy administration. Security leaders can assess the change by checking whether rules carry across their environment or require isolated maintenance and separate handling. A functioning destination control can still increase operational complexity if its management remains disconnected.

Reviews of leading zero-trust platforms increasingly describe DNS filtering as a baseline capability. Its inclusion puts greater weight on how it works within common policy and alongside the environment’s other protections. For an architecture decision, administrators need to examine how they will maintain rules and apply them across access contexts. A capability’s presence and its integration into operations are separate considerations.

Faster attacks increase the importance of timely enforcement

The broader 2025 and 2026 security picture adds pressure to make these operations faster. Attackers and defenders are expanding their use of AI, which is accelerating activity across the attack chain. Combined with software exploitation that can begin soon after disclosure, this speed makes the period before effective intervention increasingly important. Proactive, layered defenses aim to shorten that period by placing decisions where they can interrupt harmful activity.

The operational test is whether those decisions take effect in time and remain consistent as activity moves. More sophisticated dashboards offer limited practical value when enforcement systems apply policy unevenly. Security and infrastructure teams therefore need to connect visibility with the control responsible for acting on it. For destination threats, that means turning information about unsafe access into a timely DNS or site decision wherever the relevant request originates.

Key highlights

• Place controls early: DNS filtering can block dangerous domains before connections form, while site controls restrict access through browsers and managed devices. Security architects can use both to reduce exposure to phishing, malware and unsafe destinations.
• Cover each entry route: Credential abuse, excessive permissions and software vulnerabilities require distinct protections. Security leaders need to maintain identity controls, permission reviews and vulnerability management alongside destination restrictions.
• Preserve authorised access: Infrastructure teams need destination policies that block risky services while keeping essential business tools available. Evaluate deployments against exposure reduction, visibility into unsanctioned tools and the speed of legitimate work.
• Integrate policy enforcement: Separately managed controls can increase administrative complexity. Security architects evaluating DNS and site controls need to check whether rules remain consistent across cloud services, remote workers and existing access systems.
• Connect intelligence to action: Faster attacks increase the importance of timely enforcement. Security operations teams need to verify that information about malicious destinations produces effective blocking wherever relevant requests originate.