Overview

Signature Staging provides a controlled approach for validating newly added or updated attack signatures before they begin enforcing traffic. When enabled, matching requests are detected and logged without being blocked for the configured staging period, allowing you to evaluate signature behavior against production traffic before enforcement.

Use Signature Staging to:

• Reduce the risk of false positives following signature updates.
• Validate new or updated signatures against production traffic.
• Review staged signature activity using Security Analytics.
• Create exclusions or tune policies before signatures transition to enforcement.
• Balance application availability with timely security protection.

Follow these best practices to configure, monitor, and manage Signature Staging in F5 Distributed Cloud Web App and API Protection (WAAP).

Before You Begin

Review the following documentation before implementing the recommendations in this guide:

• F5 Distributed Cloud WAAP Documentation

• Create a Web Application Firewall

• Monitor Web App & API Protection

How Signature Staging Works

Signature Staging places newly added or updated attack signatures into a detection-only state for a configurable period before they begin enforcing traffic. During the staging period, matching requests are inspected and logged, but they are not blocked. This allows you to evaluate signature behavior against production traffic, identify false positives, and tune WAF policies before enforcement begins.

While a signature is in staging:

• Matching requests are allowed.
• Security events are generated for all matching requests.
• Security Analytics provides visibility into staged signature activity.
• Exclusions and policy tuning can be performed based on observed traffic.
• Signatures automatically transition to enforcement when the staging period expires.

Signature Staging Workflow

The following workflow illustrates the typical lifecycle of staged signatures:

1. Deploy new or updated attack signatures.
2. Automatically place eligible signatures into staging.
3. Detect and log matching requests without blocking them.
4. Review staged events using Security Analytics.
5. Create exclusions or update WAF policies, if necessary.
6. Automatically transition signatures to enforcement when the staging period ends.

Why Use Signature Staging?

Although attack signatures are thoroughly tested before release, application behavior varies across environments. Differences in application architecture, traffic patterns, and business logic can cause legitimate requests to match newly introduced or updated signatures.

Common factors include:

• Custom application APIs
• Legacy applications or endpoints
• Encoded or application-specific payloads
• Variable or seasonal traffic patterns
• Regional deployment differences
• Business-specific workflows

By validating signatures before enforcement, Signature Staging helps reduce the risk of false positives while maintaining visibility into potential threats. This enables you to tune policies with confidence before signatures begin blocking requests.

Benefits of Signature Staging

Signature Staging helps validate newly deployed or updated attack signatures against production traffic before enforcement begins. This reduces the risk of unexpected application impact while providing the visibility needed to tune WAF policies.

Considerations

Although Signature Staging reduces the risk of false positives, it also introduces operational considerations that should be evaluated when determining the staging duration.

For production applications, enable Signature Staging and actively review staged events throughout the configured staging period. Completing the review before signatures transition to enforcement helps reduce false positives while maintaining an effective security posture.

Critical CVE Override

One concern when enabling Signature Staging is whether it delays protection against critical vulnerabilities. F5 Distributed Cloud WAF automatically addresses this scenario by overriding the configured staging policy for critical threats.

For critical CVEs, zero-day vulnerabilities, or other high-severity threats:

• Critical signatures can bypass the staging period and move directly to enforcement.
• No manual configuration changes or administrator intervention are required.
• Emergency protections remain active even when Signature Staging is enabled.

This behavior allows you to enable Signature Staging for production applications while maintaining immediate protection against critical and emerging threats.

Choose a Signature Staging Scope

Signature Staging can be configured to apply to:

• New signatures only
• New and updated signatures

The appropriate option depends on your organization's change management process, operational capacity, and tolerance for false positives.

Stage New Signatures Only

Select this option if you want to reduce the operational effort required to review staged events while continuing to enforce existing signatures.

This option is recommended when:

• Security teams have limited capacity to review staged events.
• Existing signatures are considered stable and trusted.
• Rapid enforcement of updated signatures is preferred.

The primary trade-off is that updated signatures bypass staging. Although updated signatures undergo F5 validation before release, changes to their detection logic may still introduce false positives in some application environments.

Stage New and Updated Signatures

Select this option if you want to validate all signature changes before enforcement.

This option is recommended when:

• Applications are sensitive to unexpected blocking.
• Formal change management or compliance requirements require validation before enforcement.
• Security teams can actively review staged events during the staging period.

This option provides the greatest protection against false positives but temporarily places updated signatures back into staging until the configured staging period expires.

Recommended Configuration

Configure the Staging Duration

Configure the staging duration based on your application's traffic patterns, WAF policy configuration, and the time required to review staged events before signatures transition to enforcement.

For most production applications, a staging period of 14 days provides a good balance between operational review time and enforcement readiness. This duration typically captures both weekday and weekend traffic patterns, allowing sufficient time to validate signature behavior, identify false positives, and apply policy tuning before enforcement begins.

Consider Regional Rollouts

Attack signature updates are deployed progressively across regions as part of the standard release process. As a result, staged signatures may become active at different times depending on where your application traffic is processed.

Applications serving traffic from a limited number of regions may not observe staged signature activity until later in the deployment cycle, reducing the effective review period.

When selecting a staging duration:

• Use a longer staging period for applications that receive traffic from a limited number of regions.

• Verify that staged signature events are visible in Security Analytics across all regions processing application traffic.

• Avoid reducing the staging period until sufficient production traffic has been evaluated.

Modify the Staging Duration

You can modify the staging duration while signatures are already in staging. The updated configuration is applied dynamically to subsequent security events, allowing you to extend the staging period without redeploying signatures.

Extend the staging period if:

• Additional time is required to review staged events.
• Production traffic has been insufficient to validate signature behavior.
• Seasonal or infrequent traffic patterns require additional observation.
• Exclusion tuning or policy updates are still in progress.

End Staging Early

F5 Distributed Cloud WAF does not provide a dedicated control to immediately end an active staging period. To transition staged signatures to enforcement before the configured staging period expires, reduce the staging duration so that the staging window ends earlier.

After staged signatures transition to enforcement:

• Restore the staging duration to its standard value for future signature updates.
• Avoid leaving a shortened staging duration configured unless it aligns with your operational requirements.

Ending the staging period early should be reserved for situations where staged signatures have been fully validated and are ready for enforcement. In most cases, allowing the configured staging period to complete provides sufficient time to identify false positives and tune WAF policies.

Review Staged Signatures

Use Security Analytics to review requests that match staged signatures during the staging period. Reviewing staged events helps validate signature behavior, identify false positives, and determine whether policy tuning or exclusions are required before signatures transition to enforcement.

View Staged Signature Events

To view all security events that include one or more staged signatures, apply the following filter:

signatures.state IN Staged

This filter returns requests that matched one or more signatures currently operating in staging mode. Matching requests are inspected and logged but are not blocked while the signatures remain in staging. Use this view to understand how newly deployed or updated signatures interact with production traffic.

View Allowed Requests Matching Staged Signatures

To view requests that matched staged signatures and were allowed through the WAF, apply the following filter:

signatures.state IN Staged AND action IN allow

This filter provides a focused view of requests that could be affected when staged signatures transition to enforcement. Because it excludes requests that were already blocked by an actively enforcing signature, it helps identify allowed requests that are more likely to require review for potential false positives before the staging period ends.

Review Security Events

Review staged events to determine whether the matching requests represent:

• Legitimate attacks
• Expected application behavior
• False positives
• Automated or scripted traffic
• Internal application integrations
• Vulnerability scanning or security assessment activity

When reviewing staged events:

• Review Security Analytics regularly throughout the staging period.

• Prioritize signatures with the highest match frequency.

• Create narrowly scoped exclusions for confirmed false positives.

• Validate exclusions before staged signatures transition to enforcement.