Summary
TL;DR: F5 Distributed Cloud (F5 XC) protects sensitive data in Web Application and API Protection (WAAP) deployments in two layers: data minimization and geographic containment. First, it masks personally identifiable information (PII) before it reaches clients or logs. It does this in three places: Data Guard scrubs HTTP responses, API Security masks sensitive fields in JSON and XML payloads, and log-field masking hides sensitive header, cookie, and query-parameter values. Second, it controls where the remaining logs are stored. The Data Localization Suite stores all tenant logs in a single region you choose (currently the EU or the United States), and the Global Log Receiver streams logs to a SIEM or storage bucket you control.
This article explains each control and its limits. For example, Data Guard only sees the response your origin returns, email masking only works on Latin characters, and logs can be sampled. It also gives an 8-step walkthrough for setting up Data Guard on an F5 XC HTTPS load balancer and checking the result in Postman and the Distributed Cloud Console.
The paradox every global WAAP deployment hits
When you deploy Web Application and API Protection (WAAP) across a global network, you run straight into a tension that compliance teams and security teams experience very differently. To detect and block threats, the platform has to inspect traffic and record events. But the act of logging that traffic is exactly where sensitive customer data leaks into systems it was never meant to touch, and where data crosses borders it was never meant to cross.
A credit card number caught in a false-positive event. An Authorization token preserved in a request log. A national identifier sitting in a payload that got sampled into long-term storage. None of these require a breach to become a compliance problem. They become a problem the moment they are written down in the wrong place.
F5 Distributed Cloud (F5 XC) approaches this with what is effectively a dual-layer model:
- Data minimization. Obfuscating sensitive elements so they never land in a log or dashboard in clear text.
- Geographic containment. Keeping the logs that are retained inside a defined compliance boundary.
The rest of this post walks through both layers as they actually work in the product today, and where the sharp edges are.
Figure 1: The request and log path through F5 XC, showing where masking happens at inspection time and where residency is enforced at persistence time.
The risk of the “accidental log”
Traditional WAFs are prolific loggers by design. Every violation, every suspicious signature match, every blocked request can generate an event, and those events frequently capture the very payload that triggered them. That is useful for a SOC analyst reconstructing an attack. It is a liability when the payload contains a Social Security number, a phone number, or a session token, and that event then flows into a SIEM, a long-term archive, or a shared dashboard.
The goal is not to log less and see less. It is to ensure that the operationally useful signal survives while the regulated data does not. That is the distinction F5 XC’s privacy controls are built around.
Layer 1: PII masking and data obfuscation
“PII masking” in F5 XC is often treated as one feature. It’s actually three distinct surfaces, and a credible compliance story addresses all three.
a) Response scrubbing: Data Guard
Data Guard is the data-plane control. It inspects HTTP/HTTPS responses leaving your application and masks sensitive strings before they reach the client, replacing the matched value with a string of asterisks (*). Out of the box it recognizes credit card numbers and U.S. Social Security numbers, and you can extend it with custom PCRE regular-expression patterns for organization-specific identifiers.
Data Guard is a load-balancer feature, configured either in a WAF object attached to your HTTP/HTTPS load balancer or inline on the load balancer itself, supports rules that apply or skip processing for specific paths and routes, so you can scrub a /account response without touching an unrelated endpoint.
Figure 2: Sensitive values returned by the origin, masked by Data Guard before reaching the client.
Caveat: Data Guard acts on the response your origin returns. If an application renders sensitive data from a source that is not part of that inspected response, Data Guard will not see it. Mask-rule design has to follow where the data actually flows, not where you assume it does.
b) Structured-data detection: API Security
This is where masking is most powerful. Because APIs move highly structured data (JSON, XML), F5 XC’s API Security can discover, tag, and act on sensitive fields against hundreds of predefined data types mapped to 20+ compliance frameworks (PCI-DSS, HIPAA, GDPR, and others), with the ability to limit, mask, or block the data being exposed. A custom regex-based detector covers less-common or proprietary patterns.
The value here is selectivity: you can suppress a sensitive key inside an API payload without breaking the surrounding analytics workflow that your security team depends on.
Limitation: The platform’s automated email detection only masks email addresses written in Latin characters.
c) Log-field masking and masking-before-storage
The third surface is the logs themselves. F5 XC can mask the values of sensitive request-log fields: you specify HTTP header names, cookie names, or query-parameter names, and the values are masked while the keys remain for context. By default, values for parameters like card, pass, pwd, and password are masked.
Separately, in the platform’s observability layer, request/response payloads are captured only for API-discovery use cases, and PII content is masked in accordance with PCI-DSS before it is stored. This is the “data minimization before the sink” idea made concrete.
Best practices
- Write JSON-path and regex rules that target keys (card_number, ssn, email) rather than trying to pattern-match every possible value format.
- Treat custom PCRE patterns as first-class: the predefined frameworks will not know your internal customer-ID format.
- Validate masking from the client’s perspective (for example, Postman against the live endpoint), then confirm in the Console security event that the platform recorded why it masked, proving the control fired, not just that the field looked empty.
Hands-on: configuring Data Guard on an F5 XC load balancer
The following walkthrough configures Data Guard in front of a test application, following the same path F5’s own field walkthroughs use. Exact menu labels shift between Console releases, so pair this with the linked Create Web Application Firewall doc in Sources for current clicks.
Prerequisites
- An F5 Distributed Cloud tenant with access to the Web App and API Protection and Load Balancer workspaces.
- A reachable origin application that returns some sensitive data you can safely test with. A deliberately vulnerable lab API (such as VAmPI or a Juice Shop style app) works well.
- Optional but recommended: the application’s OpenAPI (Swagger) specification, if you want API-level discovery and masking.
Step 1: Create an origin pool
Define where your application actually lives. In the Console, create an origin pool that points at your origin server and port. This is the backend the load balancer will forward to.
Figure 3: Origin pool pointing at the test application.
Step 2: Create a Web Application Firewall (WAF) policy
Create an App Firewall object. Choose the enforcement mode: Monitoring logs and flags traffic without blocking, while Blocking actively stops malicious traffic. You will attach this policy to the load balancer in the next step.
Figure 4: App Firewall policy with enforcement mode set.
Step 3: Create an HTTPS load balancer
Create an HTTPS load balancer that references the origin pool from Step 1 and the WAF policy from Step 2. Configure your domain or domains and TLS settings. At this point you have a protected path from client to origin.
Figure 5: HTTPS load balancer wiring the pool and WAF together.
Step 4 (optional, APIs only): Add your OpenAPI/Swagger spec
If you are protecting an API, upload the application’s Swagger file and associate it with the load balancer. This gives the platform a schema to validate against and improves sensitive-data discovery inside structured payloads.
Step 5: Enable and configure Data Guard
On the load balancer, enable Data Guard and add an existing rule or create a new one inline. For each rule, set an Action (apply Data Guard processing, or skip it) and the path or route it governs. Select what counts as sensitive: credit card numbers, U.S. Social Security numbers, and any custom PCRE patterns for your own identifiers. Matched values in responses are replaced with asterisks.
Figures 6a & 6b: Data Guard rule set to apply on a chosen path.
Step 6 (optional): Turn on API and sensitive-data discovery
Enable API discovery and a sensitive-data discovery policy, adding the compliance frameworks relevant to you (PCI-DSS, HIPAA, GDPR, and so on). This auto-tags PII as it is observed in traffic and complements Data Guard’s response scrubbing.
Step 7: Validate from the client side
Call the protected endpoint from a browser or Postman. Confirm that fields which previously exposed a credit card number or SSN now come back masked. Testing from the client’s perspective is what proves the control works in the path that matters.
Figures 7a & 7b: Postman confirming sensitive values are masked.
Step 8: Confirm in the Console
Open the corresponding security event in the Distributed Cloud Console and expand the WAF and Data Guard section. You should see the event record why the data was masked. This closes the loop: you have proof the control fired, not just a field that happens to look empty.
Figure 8: Console security event confirming the masking action.
Layer 2: Localized logging and data residency
Many regulations do not only care whether data is masked; they care where the surviving records physically live. GDPR restricts transferring EU residents’ PII into regions without adequate safeguards, and many U.S. healthcare and public-sector organizations keep records in the U.S. by contract or internal policy. F5 XC offers two complementary levers here.
The Data Localization Suite (pick your logging region)
The Data Localization Suite is a subscription add-on (for an additional fee) that lets a tenant select a single logging region. Once set, **all logs, regardless of where on the global network they were generated, are stored in that chosen region and do not leave that region after ingestion. ** As of October 2026, the available choices are the EU and the United States, with F5 publicly signaling more regions to come. The U.S.-based logging region was introduced in a 2025 platform release specifically to meet localized-data-handling demand from regulated customers.
This is the cleanest way to achieve “our logs must not leave the EU”: you constrain persistence to a region rather than trying to suppress logging entirely.
Figure 9: Using a single logging region for the tenant.
Global Log Receiver (stream to a sink you control)
The complementary lever is the Global Log Receiver (GLR), which streams your tenant’s system and application logs, including the logs from your Customer Edge (CE) sites, from F5’s Regional Edges out to an external log collection system you own: a SIEM, a cloud storage bucket, or an equivalent destination. If your compliance posture requires records to land in infrastructure under your direct control and jurisdiction, GLR is how you funnel them there.
Figure 10: Global Log Receiver pointed at a customer-controlled destination.
Two things worth noting about residency
- Logs streamed through GLR to an external system, and any logs F5 retains in long-term storage (up to one year), may be sampled. If your auditors expect every record, sampling is a detail you must design around.
- “Localized” is not the same as “on-premises only.” In normal operation, a CE forwards telemetry to a Regional Edge over the F5 fabric; the residency guarantee comes from the logging-region selection and from where you point GLR, not from logs simply staying on the CE.
Persistent vs. non-persistent storage
F5 documents two storage concepts explicitly. A WAF running at a Regional or Customer Edge processes a request in main memory and then clears or overwrites it, which is non-persistent processing. Persistent storage is where data is retained to deliver the service you subscribed to. Data-residency reasoning should focus on the persistent tier, which is precisely what the Data Localization Suite governs.
Where F5 sits legally
For a compliance audience, the processor/controller relationship matters as much as the architecture. F5 operates as a processor to its Distributed Cloud customers, who are the controllers (or as a sub-processor where the customer is itself a processor); it states compliance with GDPR Article 28, participation in the EU-U.S. Data Privacy Framework, and use of Standard Contractual Clauses for relevant transfers. Sub-processor lists and framework participation change over time; see the F5 Trust Center for current details.
Bringing the two layers together
The architecture that satisfies a strict compliance officer is not “mask everything” or “localize everything”; it is both, sequenced correctly:
- At inspection time, minimize: Data Guard scrubs responses, API Security suppresses structured fields, and log-field masking keeps regulated values out of the records in the first place.
- At persistence time, contain: the Data Localization Suite pins surviving logs to an approved region, and the Global Log Receiver delivers them to a sink inside your jurisdiction.
The result is a shift from reactive privacy compliance (discovering PII in logs after the fact) to proactive, edge-driven data protection, where the regulated data is either gone or geographically contained before anyone has to go looking for it.
FAQ
What is Data Guard in F5 Distributed Cloud?
Data Guard is a load-balancer feature that masks sensitive data, such as credit card numbers, U.S. Social Security numbers, and custom PCRE patterns, in HTTP/HTTPS responses by replacing it with asterisks before it reaches the client.
How does F5 Distributed Cloud handle data residency for logs?
The Data Localization Suite, a paid add-on, stores all tenant logs in one chosen region (EU or U.S.). After ingestion, the logs do not cross national borders.
Can F5 Distributed Cloud send logs to my own SIEM?
Yes. The Global Log Receiver streams system and application logs, including logs from Customer Edge sites, to a SIEM or cloud storage bucket you control. These logs may be sampled.
Does F5 Distributed Cloud mask PII in logs?
Yes. It masks the values of specified headers, cookies, and query parameters (by default, fields like card, pass, pwd, and password). It also masks PII in captured API payloads in line with PCI-DSS before they are stored.
Sources and further reading
- F5, Create Web Application Firewall (Data Guard configuration): docs.cloud.f5.com
- F5, Observability (PCI-DSS masking before storage; sampling): docs.cloud.f5.com
- F5, Distributed Cloud API Security (limit/mask/block, compliance frameworks): f5.com
- F5, API Endpoint Discovery (email-masking limitation): docs.cloud.f5.com
- F5, Local data storage: A necessity for regulated industries (Data Localization Suite): f5.com
- F5, Platform release blog (U.S. logging region launch): f5.com
- F5, Configure Global Log Receiver: docs.cloud.f5.com
- F5, Data Residency and Processing Reference: docs.cloud.f5.com
- F5, GDPR and Data Protection Framework (Trust Center): f5.com
- DevCentral, Mitigating OWASP API Security Risk: Excessive Data Exposure using F5 XC: community.f5.com