Documentum Trusted Content Services add on licensing

Trusted Content Services adds encryption, electronic signatures, and stronger security controls to a Documentum repository. It is licensed separately from the base platform, and that separation is exactly what an audit can blur, charging every base user for an add on that only a subset of them ever uses.

A Documentum estate is rarely a single product. The base Content Server sits at the centre, and around it run optional modules that extend what the repository can do, Trusted Content Services among them. These add ons carry their own entitlements and their own metrics, and the relationship between an add on and the base platform is where a finding can quietly inflate. The trap is not subtle once you see it: an audit can assume that because a module is installed on the server, every base user is also a user of the module, and charge the add on across the whole population rather than the part of it that genuinely uses the capability. The licensed scope of Trusted Content Services and similar add ons is what the entitlement defines, not what the server installation implies. Because the OpenText EULA places compliance on the licensee, establishing the genuine add on scope is the buyer's responsibility.

How add on modules are licensed against the base

An add on like Trusted Content Services is licensed in addition to the base Documentum platform, and its metric may differ from the base seat count. It might be licensed to a defined subset of users, to specific repositories, or to a particular volume of secured content, depending on the agreement. The critical point is that being entitled to and using the base platform does not, by itself, mean a user consumes the add on. A person who reads and edits documents through the Content Server may never invoke the encryption or signature capabilities that Trusted Content Services provides. The add on count is the count of users or repositories that actually use the add on functionality, scoped by its own entitlement, not the base population inherited wholesale.

The principle to hold to is that each licensed component is measured against its own metric and its own genuine usage. The base seat count answers the base entitlement; the add on count answers the add on entitlement. Collapsing the two, so that base usage is treated as add on usage, charges for a capability the user never touched.

Where an add on finding overstates

Whole base population charged for the add on

The central overstatement is applying the base seat count to the add on, on the assumption that installation equals universal use. The correction is to identify the users or repositories that actually invoke the add on functionality, which is the same usage based discipline set out in reducing a Documentum finding with usage evidence.

Add on counted on non production or dormant deployments

An add on installed in test environments or on dormant repositories is not generating production consumption. Counting it there inflates the figure with capacity that serves no live use, the boundary argued in Documentum non production environments and license claims.

Module bundling read in the vendor's favour

Whether an add on was bundled into a base purchase or licensed separately is a question of the entitlement, and an ambiguous bundle can be read either way. Reading it precisely against the contract is part of the wider interpretive work in our ALA and entitlement review track, and it connects to the platform versus module question in Content Suite platform versus module licensing.

Defending an add on finding under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. In that window we take over the channel and ensure the add on installations, their entitlements, and the usage of the add on functionality are documented before the module is charged across the base population.

Reconstruct. We build the effective license position independently. We separate each add on from the base platform, identify its own metric, establish the users or repositories that genuinely use the add on capability, and exclude non production and dormant deployments. The reconstructed position counts each add on against its real scope.

Rebut. We challenge the finding line by line. Where the base population has been charged for the add on, we show the genuine add on usage. Where non production deployments have been counted, we scope them out. Where a bundle has been read in the vendor's favour, we apply the entitlement. Each correction rests on the usage evidence and the add on metric.

Resolve. We settle on the corrected position and, where it serves you, convert forward into an OpenPass agreement that records how each add on is scoped and measured against the base, so the next audit cannot charge a module across the whole platform.

An anonymised outcome

The reason an add on overstatement is expensive is the standard remedy. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so charging an add on across an entire base population multiplies through four charges. In our anonymised insurance engagement, case file E-01, a Documentum centred ECM finding fell from $7.2M to $1.6M, a 78 percent reduction, by holding every count to what was genuinely used. The same discipline that disqualified ineligible base accounts applies directly to an add on charged beyond its real scope.

Measure the add on, not the assumption

The lasting lesson is that an add on like Trusted Content Services is a separate licensed component with its own scope, and a finding that charges it across the base platform is substituting an assumption for a measurement. Installation on the server proves capability, not consumption, and the gap between the two is often large because security and signature features are used by a defined group rather than everyone. The buyer who establishes genuine add on usage corrects that gap, and the correction is frequently among the cleaner reductions on a Documentum finding because the entitlement and the usage records speak so directly to it.

For a buyer, the practical step is to inventory every add on module, record its entitlement and metric separately from the base, and document which users or repositories actually use each capability. To prepare that material, read how to reconcile Documentum entitlements before an audit, and to see how add ons fit the wider defense, read our ECM and Documentum audit defense track. If a finding has charged an add on across your whole base population, open a case.

Where to go next

For the full method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026. To understand the platform versus module distinction that underlies add on scope, read Content Suite platform versus module licensing.