What are the signs that a SASE or SSE programme is being designed around tools instead of control points?

How to tell the architecture is being organised around products

The first clue is that the team can name vendors but not enforcement points. In a control-point design, the conversation starts with what each layer must stop, inspect, or broker. In a tool-led design, the conversation starts with which box owns the feature, which license includes it, and which team is “responsible” for it.

That usually shows up as duplicated decisions and blurred boundaries. DNS filtering, secure web gateway controls, cloud access security broker functions, and ZTNA should each answer a different enforcement question. If the same policy is being rewritten in multiple consoles, or if no one can describe the unique role of each layer, the programme is probably assembled from product capabilities rather than from a coherent control model.

Another sign is that exceptions become architecture. Instead of mapping threats to the right choke point, teams keep adding product-specific workarounds, overlapping policy sets, and one-off bypasses. The result is a stack that looks complete on a slide but behaves inconsistently under real traffic, because ownership and enforcement logic are not the same thing.

Where control-point thinking should be obvious

A sound SASE or SSE design is easier to explain in verbs than in products. DNS should block or steer name resolution abuse, SWG should inspect and govern web access, CASB should control cloud app use and data handling, and ZTNA should mediate access to private applications. If the architecture cannot explain that division cleanly, it is missing a control model, even if the product list is impressive.

This is why product overlap is not automatically a problem, but unexplained overlap is. Some organisations will intentionally use more than one vendor or more than one inspection path, especially during migration. The design becomes unhealthy when overlap exists without a decision rule for which control wins, which telemetry is authoritative, and which team owns each policy outcome.

A useful test is whether the programme can survive a vendor swap without rewriting the security intent. If replacing a SWG, CASB, or ZTNA component would require redefining the threat model from scratch, then the architecture is too tightly coupled to the tool. Control points should outlast the specific product that implements them.

What a control-led SASE or SSE programme looks like in practice

Control-led programmes begin with threat and access outcomes, then choose products to implement them. That usually means clear policy intent, explicit layer responsibility, and shared language for where inspection, identity checks, data controls, and private-app access decisions occur. It also means the platform design is evaluated on whether it preserves those decision points consistently across branches, users, cloud apps, and third parties.

For a reference architecture and the common trade-offs between single-vendor and multi-vendor designs, see the SASE and SSE Guide. For buyers trying to separate product claims from architecture choices, the SASE and SSE Buyer’s Guide is the better lens because it forces the evaluation back onto PoP behaviour, identity integration, and resilience rather than feature names.

When teams can articulate the control point, they can also test it. That is the practical difference between “we bought SSE” and “we know exactly which threats are blocked where.” The second statement is what makes migrations governable, policy auditable, and exceptions reviewable.

Risk and Threat Considerations

A tool-led SASE or SSE programme creates policy drift and blind spots because the same access request can be interpreted differently by different products. That makes it harder to prove where a threat was blocked, where it was merely logged, and where it passed through uninspected.

Failure mechanism: Control responsibilities are duplicated or left ambiguous, so policy enforcement becomes inconsistent across DNS, SWG, CASB, and ZTNA layers. Teams then rely on vendor feature lists instead of a defined enforcement chain.

Impact: Gaps in inspection and access control become harder to detect, exceptions accumulate, and incident response loses clarity about which layer should have prevented the event.

Practitioner Guidance

What to verify: Ask the programme owner to describe, in one sentence per layer, what DNS, SWG, CASB, and ZTNA each block, inspect, or broker. If the answer requires product names before it can explain enforcement logic, the design is not yet mature.

Common mistake: Treating feature overlap as architecture. Overlap is acceptable only when there is a deliberate decision rule for precedence, telemetry ownership, and exception handling.

What good looks like: You can remove a product from the conversation and still explain the control model, the threat each layer addresses, and the fallback if that layer is unavailable.

Practitioner takeaway: A credible SASE or SSE design is defined by control points first and tooling second; if the team cannot name the enforcement logic, the platform has probably been designed backwards.

Related resources from NHI Mgmt Group

• What happens when a SOC is designed around tools instead of mission and process?
• What are the signs that an EPCS rollout is being designed around convenience instead of real clinical workflow?
• What are the signs that a governance programme is optimised for documentation instead of control?
• How should teams think about ServiceNow in an NHI programme?