Sensitive Data Redaction
Device configurations contain credentials, pre-shared keys, SNMP communities, and other secrets. Many organizations don't want that material leaving the device, even into an internal analysis tool. Redaction strips or hashes those fields on the collector before any configuration data is written to disk or uploaded — Forward Enterprise only ever stores the redacted form.
Once redacted, the original values cannot be recovered in Forward Enterprise.
Configuration
Redaction is configured at the organization level under Platform → Collectors → Organization collection settings → Advanced → Sensitive data redaction. The algorithm and patterns set here apply to every network in the organization.
A workspace network can override the redaction algorithm without affecting its parent — see Per-network redaction overrides below.

Redaction algorithm
You can select one of the following algorithms:
| Option | Description | Example Result |
|---|---|---|
| None (disabled) | Redaction is turned off. Device configurations are collected as-is, with no masking or hashing. | enable secret 9 $9$ARZqWZRGsp.OuE$VF1epfXv.7 |
| Mask only | The default option. Sensitive fields are replaced with a generic mask (e.g. <redacted>). The configuration structure remains intact. | enable secret 9 <redacted> |
| MD5 hash (16 digits) | Sensitive values are replaced by an MD5 hash to preserve uniqueness while obscuring the value. | enable secret 9 <redacted:5D965E923B66E538> |
- None (disabled) — Use when full configuration visibility is required, for example when relying on Forward Enterprise as a configuration archive or running NQE queries that need cleartext fields.
- Mask only — Use when no trace of authentication material should appear in collected files. Removes the ability to detect or compare changes in those fields.
- MD5 hash (16 digits) — Use to track changes in sensitive fields without exposing values. Identical cleartext produces the same hash, so external tools can detect when a secret rotates.
Some devices store authentication material in their own hashed form (SHA256, MD5, or vendor-proprietary). When the collector re-hashes those values with MD5, the same cleartext on two devices can produce different hashes — apparent changes in sensitive fields may just reflect different device-side encodings.
Hierarchical pattern filters
In addition to the built-in vendor-specific redaction rules, you can define your own hierarchical pattern filters to
remove specific configuration lines or sections from collection.
These filters are evaluated by the Forward Collector during data collection, allowing you to exclude additional
sensitive or irrelevant information before it is stored.
Pattern syntax
Forward Collector supports two types of filters:
- Word globs
- Regular expressions
Both types are case-sensitive by default and not anchored to the beginning or end of a line.
Word globs
Word globs use wildcard characters to match text patterns:
*— matches any sequence of non-whitespace characters?— matches a single non-whitespace character
A matching line can contain non-matching words before and after the matched portion.
Regular expressions
Regular expressions (regex) can be used for advanced matching:
- Case-sensitive by default; add
(?i)at the beginning for case-insensitive matching. - Not anchored by default; use
^to anchor to the start of a line, and$to anchor to the end.
Tree (hierarchical) patterns
Multi-level tree patterns can match hierarchical configuration data (such as indentation-based Cisco syntax or
structured Juniper configurations).
Each level is separated by a / in the pattern.
By default, multi-level matching is anchored-inside:
- A match can begin and end at any level in the hierarchy.
- Levels cannot be skipped unless you use
**(wildcard for one or more levels).
Usage notes
- Place one expression per line.
- Test filters carefully — filtering out configuration that affects routing or forwarding can alter analysis results.
- Custom filters are applied in addition to built-in vendor/OS redaction patterns.
Per-network redaction overrides
Each network — including workspace networks — can use a different redaction algorithm than the organization default. Hierarchical pattern filters and every other Advanced-tab setting always come from the organization.
At collection time, the algorithm is resolved in this order:
- The override registered for the workspace itself, if any.
- The override registered for the parent network, if any.
- The organization default.
To register an override:
- Open Organization collection settings → Advanced → Sensitive data redaction.
- Expand Redaction algorithm override per network.
- Click Add override, select the network, and choose the algorithm.
If the override matches the organization default, no override is recorded.
What is considered sensitive data
The Forward Collector ships with built-in vendor- and OS-specific redaction patterns. These cover more than just login credentials:
-
Authentication and access credentials:
Passwords, secrets, and shared keys used for device login, AAA, or SNMP access. -
Routing and control-plane security:
Authentication keys, pre-shared keys, or password fields used in routing protocols (e.g., BGP, OSPF, EIGRP, IS-IS). -
Encryption and certificate material:
Private keys, crypto configurations, and certificate blocks. -
Management and monitoring data:
SNMP communities, syslog or NTP authentication keys, and API tokens.
Built-in patterns are maintained by Forward Networks and differ per vendor and OS. They are updated as new vendor releases ship.