Broadcom Data Masking: Capabilities and Limitations

Enov8 Context(4).docx
Document
Search Visibility and Content Context(4).docx
Document
Editorial Context(4).docx
Document

I'm going to share a draft blog post for https://enov8.com/. See example posts on their site and also the guidelines that I've attached here. Make sure that the post follow's those guidelines, isn't passive. Make sure things aren't too repetitive. Draft is below:

Broadcom Data Masking: What It Does and Where It Falls Short

TL;DR: Broadcom's data masking lives inside CA Test Data Manager (CA TDM), where it replaces sensitive production values with realistic but fictitious substitutes so your test environments never hold real PII. You configure it through the TDM Portal, assigning masking functions by table or by tag, and run the work through the Fast Data Masker engine, which can run in Docker for scale. It does the core job well, but it comes with real friction: a hard concurrency cap, schemas that queue behind that cap, and infrastructure planning overhead. This post explains how the capability works and where it strains, then points to what teams with complex test-data needs often weigh alongside it.
Test data is where a lot of quiet risk lives. Every time a team spins up a new environment, duplicates a database for analytics, or shares a dataset with a vendor, a copy of sensitive data spreads a little further. Without clear governance, protection turns inconsistent as those copies multiply.
Getting it wrong is expensive. Drawing on IBM's 2025 Cost of a Data Breach Report, Huntress reports that the average breach now runs $4.4 million globally, climbing to $5.56 million in finance and $7.42 million in healthcare.
Masking is how teams pull sensitive data out of that blast radius. Here's how Broadcom does it.

What Broadcom Data Masking Is

Data masking replaces sensitive information — PII, financial data, protected health information — with fictional but realistic substitutes, as Dataintelo describes it. The point is to keep the data usable for testing while making it useless to anyone outside its authorized context.
In the Broadcom ecosystem, data masking lives inside CA Test Data Manager (CA TDM), where it swaps real production values for realistic fictitious ones so test environments never expose regulated data.
The work happens in the TDM Portal. Broadcom's documentation explains that the TDM Portal folds tasks that once required separate tools into one place, and a test data engineer masks data there using the Fast Data Masker engine.
One constraint shapes everything downstream: masking is scoped to a data model. Per Broadcom's docs, you can only mask data that sits in a CA TDM data model. Define the model first, then mask what's in it.

How the Masking Process Works

Underneath the portal, masking in CA TDM runs on the Fast Data Masker (FDM) engine. Broadcom's documentation explains that the portal uses FDM to mask data, and its masking functions are specific to data types such as VARCHAR, DATE, and NUMBER.
Those functions get bundled into reusable configurations. The docs define Mask Function Groups as configurations of masking functions, set in an execution order with seedlists as parameters where appropriate, that the portal uses to generate FDM jobs. Here's what one looks like: the built-in "Post Code (UK)" group contains a single masking function, HASHLOV, and specifies the "UK Post Codes" seedlist as its parameter.
The next three sections walk through how you configure a job, how the engine runs it, and what happens at runtime.

1. Configuring Masking Jobs in the TDM Portal

Masking in the portal is tag-driven. Broadcom's docs explain that the portal masks columns with Mask Function Groups based on tags you assign to columns, and you can assign those tags two ways: through a PII scan or manually. From there, the flow moves through select model, configure, masking settings, and start masking, with each run tracked on the Masking Jobs page.
You have two paths for reviewing and adjusting what gets masked. One is the table view, where the docs note that each row represents a tag in the data model. Clicking the plus icon opens the expanded tag view, which surfaces the tag's default Mask Function Group.
That second view is where the nuance shows up. If you mask columns carrying the same tag with different functions, the field displays "Multiple functions." One tag can fan out into several distinct masking behaviors.

2. How the Remote Masking Engine Operates in Docker

Starting with Test Data Manager 4.8, Broadcom made the Masking Engine available as a Docker container. Per the docs, the Masking Engine container performs masking tasks with the Fast Data Masker engine. It doesn't act alone.
Between the portal and the engine sits a messaging layer. Broadcom's documentation describes a Messaging container holding a Java Messaging Service queue of the tasks that make up a masking job, distributing them to the engine containers over RabbitMQ. The engine containers pick tasks off that queue and do the actual masking.
The reason for this architecture is scale. The docs explain that it lets you distribute masking jobs across multiple hosts to run concurrently. That power comes with setup cost. The same guidance tells you to pull a specific Apache ZooKeeper Docker image before scaling out.

3. What Happens at Runtime

At runtime, the flow moves one direction through the stack. Broadcom's docs describe how the TDM Portal service, whether running in Windows or Docker, sends masking jobs — split into tasks -- to the messaging container, which hands those tasks to the engine containers, which perform the masking with FDM.
How that plays out depends on how you've deployed it. Broadcom documents four topologies, ranging from portal and engines both in Docker to the portal in Windows with engines in Docker. The right shape depends on your existing infrastructure and how much you need to scale.
The result on the other side is a provisioned test environment carrying structurally intact data with the sensitive values swapped out. Bloor Research notes that CA TDM keeps masked data referentially intact, is fully auditable, and can mask millions of rows in minutes either in-place or in-flight. That referential integrity is what makes the masked output usable for real testing.

Where Broadcom Data Masking Has Limits

The tool does the core job, and does it in a compliant, auditable way. But a practitioner should go in knowing where the friction is. The first is concurrency. Broadcom's own guidance sets a hard ceiling of four concurrent FDM instances, both the default and the recommended maximum, since more than that loads the host too heavily.
That cap bites harder the more schemas you have. The same documentation treats each database or schema as one masking task. With ten single-schema connection profiles and a maximum of four instances, four run and the other six queue until an instance frees up. Masking across many schemas isn't parallel. It's throttled by that ceiling.
There's also an infrastructure planning burden. The docs note that total memory for a job equals the sum of memory across every concurrent FDM instance, so resource needs scale linearly with parallelism. Add Docker containers, a messaging layer, a ZooKeeper dependency, custom seedtables that must be copied into the right volume, and four possible deployment topologies, and the honest summary is that the capability is powerful but standing it up and scaling it takes real work.

What to Consider Alongside It

Organizations with complex test-data needs rarely rely on a single tool. Masking is one layer. Provisioning realistic environments fast, without duplicating full production datasets, is another. When the schema count is high or environments need to spin up quickly, teams often look at how their masking approach fits the rest of their test-data pipeline.
If you're weighing where Broadcom's approach has gaps — around scaling, environment provisioning, or lightweight test data on demand -- it's worth seeing how Enov8's Virtualize handles environment and test-data delivery, and where Enov8's broader test data management capabilities complement or replace what you have. The point isn't swapping tools for their own sake. It's making sure the masking layer and the

Shorten this title slightly:

Broadcom Data Masking: What It Does and Where It Falls Short

Broadcom Data Masking: Capabilities and Limitations

Give me a meta descriptin

Learn how Broadcom data masking works in CA TDM, its key capabilities and limitations, and what to consider for complex test data needs.

Now generate a featured image for this post based on the ones on Enov8's site and don't include any text

Created a text-free featured image for the Broadcom data masking post, using Enov8’s blue, polished enterprise-technology aesthetic.

Edit
Give me alt text

Secure database protected by a digital shield as masked data flows across a connected network.

Test data creates a significant but often overlooked source of risk. Every time a team creates an environment, copies a production database, or shares a dataset with a vendor, sensitive information spreads further. Without clear governance, data protection becomes inconsistent as those copies multiply.

The financial consequences can be substantial. Drawing on IBM’s 2025 Cost of a Data Breach Report, Huntress reports that the average breach now costs $4.4 million globally. The average rises to $5.56 million in the financial sector and $7.42 million in healthcare.

Data masking reduces this exposure by removing sensitive values before teams use production-like data outside production. Here’s how Broadcom approaches it.

What Broadcom Data Masking Is

Data masking replaces sensitive information—including personally identifiable information (PII), financial records, and protected health information—with fictional but realistic substitutes. The goal is to preserve the structure and usefulness of a dataset without exposing the original values.

Broadcom provides this capability through CA Test Data Manager (CA TDM), which masks production data before teams use it in development, testing, and other nonproduction environments.

Users manage the process through the TDM Portal. Broadcom’s documentation explains that the portal brings together tasks that previously required separate tools. Test data engineers can identify sensitive columns, assign masking rules, start jobs, and monitor their progress from one interface.

CA TDM scopes each masking job to a data model. According to Broadcom, the portal can only mask data included in a CA TDM data model. Teams must therefore define and maintain the model before they can mask the corresponding data.

Build yourself a test data management plan.

How the Masking Process Works

CA TDM uses the Fast Data Masker (FDM) engine to execute masking jobs. FDM provides functions for data types such as VARCHAR, DATE, and NUMBER.

Teams combine those functions into reusable Mask Function Groups. Each group defines which functions to run, their execution order, and any required seedlists. For example, Broadcom’s built-in “Post Code (UK)” group uses the HASHLOV function with a UK postal code seedlist.

The masking workflow has three primary stages.

1. Configure Masking Jobs in the TDM Portal

The portal uses tags to determine which columns to mask and which functions to apply. Teams can assign tags manually or through a PII scan. They then select a data model, review the proposed masking configuration, adjust the settings, and start the job. The Masking Jobs page tracks each run.

The portal provides two ways to review the configuration. In its table view, each row represents a tag in the data model. Expanding a tag reveals its default Mask Function Group and the columns associated with it.

Users can also apply different functions to columns that share the same tag. When they do, the portal displays “Multiple functions” for that tag. This flexibility allows one classification, such as a customer identifier, to trigger different masking behavior depending on the column or system.

2. Run the Masking Engine in Docker

Broadcom introduced a Docker-based Masking Engine with Test Data Manager 4.8. The Masking Engine container uses FDM to perform the masking work.

A messaging layer connects the portal to the engine containers. Broadcom describes a Messaging container that maintains a Java Message Service queue and distributes masking tasks through RabbitMQ. Available engine containers retrieve tasks from the queue and process them.

This architecture lets teams distribute work across several hosts. However, it also introduces infrastructure that teams must configure and support. Broadcom’s scale-out instructions, for example, require a compatible Apache ZooKeeper image in addition to the portal, messaging, and masking containers.

3. Execute and Monitor the Job

At runtime, the TDM Portal service divides a masking job into tasks and sends them to the messaging container. The messaging layer distributes those tasks to the available engine containers, which run FDM against the target data.

Broadcom documents four deployment topologies. Teams can run both the portal and engines in Docker, run the portal on Windows with Docker-based engines, or use one of the other supported combinations. The best topology depends on the organization’s existing infrastructure, operating model, and scaling requirements.

The resulting dataset retains its structure while replacing sensitive values. Bloor Research notes that CA TDM can preserve referential integrity, maintain an audit trail, and mask data in place or in flight. Referential integrity matters because applications still need valid relationships among customers, accounts, transactions, and other records after masking.

Where Broadcom Data Masking Has Limits

CA TDM covers the essential masking workflow, but large or complex implementations can expose several points of friction.

The first involves concurrency. Broadcom’s performance guidance for CA TDM 4.9 recommends a maximum of four concurrent FDM instances. Broadcom warns that additional instances can place too much load on the host.

That limit becomes more noticeable when a job spans several schemas. CA TDM treats each database or schema as a separate masking task. If ten single-schema connection profiles enter the queue while four FDM instances are available, the system processes four tasks while the other six wait for an instance.

Teams must also plan capacity carefully. Broadcom calculates the total memory requirement by adding the memory allocated to every concurrent FDM instance. Increasing parallelism therefore increases memory consumption proportionally.

The broader deployment also includes several moving parts: Docker containers, RabbitMQ messaging, ZooKeeper, data-model maintenance, deployment-specific configuration, and seedtables that teams must place in the correct volumes. None of these requirements prevents CA TDM from working at scale, but they increase the engineering and operational effort required to deploy and maintain it.

What to Consider Alongside Broadcom Data Masking

Organizations with complex test data requirements should evaluate more than the masking engine itself. Masking protects sensitive values, but teams must still discover that data, validate the results, provision environments, maintain reusable datasets, and deliver data quickly enough to support development and testing.

A broader test data management solution can connect masking with data profiling, compliance validation, subsetting, synthetic data generation, reservations, and operational insights. When evaluating Broadcom or complementary technology, consider how well the overall solution addresses these questions:

Can it automatically locate sensitive information across different data sources?
Does it verify that masking worked and that no protected values remain?
Can teams provision smaller or virtualized datasets instead of copying full production databases?
Can developers and testers request data without depending on a specialist for every job?
Does the platform coordinate masking, provisioning, reservations, and compliance reporting?

For teams struggling with slow or storage-heavy database copies, database virtualization can complement masking by creating lightweight, isolated copies of production-like databases. Enov8 VirtualizeMe integrates with Enov8 Test Data Manager so teams can secure data during ingestion and then provision masked database clones for development and testing.

Broadcom CA TDM remains a capable masking option, especially for organizations already invested in its data models and portal. However, teams should evaluate the full operational picture—not only whether a tool can mask data, but also how quickly it can discover, secure, validate, and deliver that data across the software development lifecycle.