Why Blocking Mode Isn’t Working: The Hidden Risk of “Transparent Forever”

Transparent mode is not the problem. Forgetting to move beyond it is. 

1. Transparent mode is meant to reduce deployment risk

You use transparent mode while learning traffic, reviewing violations, tuning signatures, and understanding false positives.

When building a policy, the Enforcement Readiness Period should not become an open-ended delay. A target date for moving the policy towards blocking should be set early, often after three or four ERP cycles, depending on the application, traffic volume, and review process. It is a good idea to publish the "block mode date" on day one of the policy deployment, if possible.

In my training, we look at how to use transparent mode properly, without allowing it to become the permanent state of the policy.

2. But the transparent mode does not stop the attack

The policy may detect SQL injection, XSS, bad parameters, evasion techniques, or protocol violations, but the request can still reach the application.

Policies are not usually left in transparent mode as a deliberate monitoring strategy. They are more often left there because the team is worried about false positives and the possible impact of moving to blocking mode.

In my training, we test this behaviour directly so you can see the difference between detecting an attack and actually stopping it.

3. “We’ll block it later” often becomes permanent

Teams get nervous about false positives, application owners lose interest, and nobody owns the final move to blocking.

The policy is forgotten, and the next time it gets serious attention is often when the organisation becomes aware of a problem, or when a penetration test shows that attacks are still reaching the application.

In my training, we cover how to move from intention to action, so blocking becomes a controlled step rather than something postponed forever.

4. A transparent policy can create false confidence

Dashboards show violations. Reports show activity. ASM looks deployed.

But the application may still be exposed.

This can create a misleading view of the application’s security posture. The organisation may be able to say “we have a WAF deployed”, but that does not mean the WAF is actively protecting the application.

In my training, we separate visibility from protection, so you can understand what ASM is showing you and what it is actually enforcing.

5. Blocking needs a controlled process

Blocking should not mean turning everything on and hoping for the best.

A proper process means reviewing violations, tuning noise, deciding what is safe to block, testing the impact, and then gradually moving protections into blocking.

Blocking mode can often be enabled sooner than teams think. False positive issues can be handled carefully in blocking mode without breaking the application. F5 ASM provides several ways to manage enforcement, including staging, learning, alarm-only violations, selective blocking, and policy tuning while the application remains protected.

If your ASM policy has been transparent for months, you may not have a WAF deployment. You may have a very expensive alarm system.

In my training, we work through that controlled process, including how to decide what can be blocked safely and what still needs investigation. 

If your ASM policy has been transparent for months, you may not have a WAF deployment. You may have a very expensive alarm system.