Should organisations replace WAF and RASP with application visibility?

Why application visibility is different from WAF and RASP

WAF and RASP sit at the perimeter or inside the application to block or detect known bad patterns, but they do not give SOC teams the full runtime story. Application visibility is about seeing the requests, decisions, dependencies, and execution context that explain why the application behaved a certain way. That matters because security teams often need evidence, not just prevention.

A useful way to think about the three is that WAF reduces attack surface, RASP can stop or instrument specific in-process abuse, and application visibility helps reconstruct what happened when the earlier layers are bypassed, misconfigured, or simply not expressive enough. The controls are complementary because each answers a different operational question.

In practice, teams should expect visibility to improve triage and investigation more than outright prevention. It is strongest when it shows what the application actually received, which business flow was invoked, and whether the observed behavior matched the control assumptions. That makes it useful for both security operations and engineering follow-up.

Where WAF and RASP still earn their place

Replacing WAF and RASP outright usually removes valuable control points. WAF still helps with broad attack filtering, protocol abuse, and high-volume commodity traffic, while RASP can detect certain exploit attempts inside the process and sometimes stop them close to the point of use. Those strengths matter when the question is reducing exposure before it reaches the application.

Application visibility does not substitute for all of that because it is not primarily a blocking layer. It is better at explaining runtime behavior than preventing it. If an organisation uses only visibility, it may gain insight but still leave itself dependent on upstream controls for first-line prevention and for rapid containment of obvious malicious traffic.

The practical decision is rarely “which one wins.” The better question is whether the organisation needs a prevention control, an in-process detection layer, runtime evidence, or some combination. For many teams, the answer is still all three, with clear ownership for each layer.

Teams that want structured application testing and runtime control expectations can anchor their appsec verification around OWASP ASVS, which maps well to authentication, authorization, and session-related failure modes that visibility often has to help explain. When the question is whether a technique is being actively exploited in the wild, CISA Known Exploited Vulnerabilities Catalog is a useful external reference for prioritising what deserves the most attention first.

What application visibility changes for SOC teams

Application visibility is most valuable when the security team needs to answer “what actually happened inside the app?” instead of “did the edge filter match?” It can reveal failed access checks, abnormal business-flow sequencing, unexpected backend calls, and runtime signs that a request was accepted, transformed, or forwarded in ways a perimeter control would not show.

That makes it especially useful for investigating bypasses, false negatives, and ambiguous alerts. If a WAF blocks too much, visibility helps prove the business impact. If a WAF misses something, visibility helps show the runtime path the attacker tried to use. If RASP fires, visibility helps correlate the event to surrounding application state and downstream effects.

For teams operating modern APIs and web services, OWASP Web Security Testing Guide is a helpful companion because it aligns testing with the kinds of application behaviours visibility should surface. For containerised workloads and runtime context, NIST SP 800-190 Container Security helps frame the boundary between platform controls and application-level behaviour.

Visibility also improves communications between security and engineering. Instead of sending a generic alert, SOC teams can provide evidence that a specific endpoint, code path, or backend dependency behaved unexpectedly. That shortens investigation time and makes remediation more concrete.

How to decide whether to augment, not replace

The best decision rule is to replace only when the old control is redundant for the risk you are trying to manage. In most environments, WAF and RASP remain useful because they reduce exposure at different points in the attack path, while visibility improves detection, investigation, and accountability. Dropping them without proving equivalent prevention and runtime protection is usually a regression.

Application visibility is most defensible as a control multiplier when the organisation has complex services, high-value transactions, or frequent incident triage across teams. In those cases, the missing capability is often not another block rule, but trustworthy runtime evidence that can be acted on quickly.

If your programme depends on secure authentication, token handling, or access decisions, the most useful visibility is the kind that shows whether the app actually enforced those decisions under load and edge cases. That is where RFC 9449: OAuth 2.0 Demonstrating Proof of Possession and RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants become relevant as reference points for stronger runtime trust assumptions.

The practical endpoint is straightforward: use WAF and RASP where they materially reduce exposure, and add application visibility where you need proof of behaviour, faster triage, or better post-incident reconstruction. The visibility layer is most valuable when it closes the evidence gap, not when it is asked to do every other control’s job.

Practitioner takeaway: Treat application visibility as an evidence and investigation capability that strengthens WAF and RASP, not a blanket substitute for either one.

Related resources from NHI Mgmt Group

• When should organisations treat application visibility as more than a nice-to-have control?
• How should security teams layer WAF, RASP, and ADR for application protection?
• What is the difference between RASP and WAF in application protection?
• What should organisations do after a WAF signature blocks an XSS exploit in a VPN application?