Agile PLM lets an administrator switch on modules you never bought, and Oracle knows it. This guide shows how PPM, PQM, PCM, and Engineering Collaboration drift out of entitlement, how Oracle quantifies the gap, and the moves that cap your exposure before the audit letter arrives.
Agile PLM lets an administrator switch on modules you never bought, and Oracle knows it. This guide shows how PPM, PQM, PCM, and Engineering Collaboration drift out of entitlement, how Oracle quantifies the gap, and the moves that cap your exposure before the audit letter arrives.
After 25 years across the table from Oracle on application deals, I can tell you the Agile PLM findings almost never involve anyone deliberately stealing software. They involve a dropdown. Oracle designed Agile so that access to a license key file is not a grant of entitlement, and the license keys provided for download do not technically enforce the license restrictions or restrict use of the products. That is Oracle's own language, and it is the entire foundation of this problem. The software will run whatever you turn on. Your contract, not the software, defines what you are allowed to run.
The enabling mechanism is trivial. An administrator opens the Modules tab of the Licenses node and selects the PLM solutions the company has purchased. Selecting Yes enables those PLM classes and functions and disables the ones that do not apply. The only guardrail is a soft honor-system prompt on save: "Please verify your company is contractually licensed to use the modules selected." There is no license file check, no key validation, no lockout. Someone clicks Yes, restarts the system, and a module you never bought is now live and generating usage data that Oracle can read three years later.
The software will run whatever you turn on. Your contract, not the software, defines what you are allowed to run. That gap is the audit.
This is why we treat Agile module sprawl as a configuration and governance failure rather than a compliance intent question. Oracle does not care about intent during a review. It cares whether the module was enabled and used. For the metric side of this exposure, read our breakdown of Agile PLM Named User versus Concurrent user costs, because the module gap and the user-count gap compound in a single finding.
Four modules account for the bulk of Agile module sprawl we see: Product Portfolio Management (PPM), Product Quality Management (PQM), Product Cost Management (PCM), and Engineering Collaboration. Each is licensed separately, each carries its own Named User Plus (NUP) count, and each can be switched on independently of what you actually purchased. Here is what each does and why it gets enabled by accident.
| Module | Function per Oracle documentation | Why it drifts into use |
|---|---|---|
| PPM (Product Portfolio Management) | Integrates project and product information across the portfolio and lifecycle to streamline development processes | Project managers want a portfolio view; an admin toggles it on to demo capability |
| PQM (Product Quality Management) | Manages customer, supplier, and product quality issues through a closed-loop corrective action process | Quality teams start logging CAPAs and issues without anyone checking the entitlement |
| PCM (Product Cost Management) | Manages product costs across the lifecycle and synchronizes cost processes with internal and external participants | Sourcing and cost teams enable cost rollups tied to the BOM they already use |
| Engineering Collaboration | Manages CAD design data directly in the central PLM record and automates BOM change processes | Engineers connect CAD tools; the connector requires the module, so it gets switched on |
There is a specific dependency trap worth flagging. Product Portfolio Management is the only Agile solution that can operate without Product Collaboration (PC). But Oracle's own administrator guide states it is likely that even a company using only PPM will also use PC. So a PPM-only entitlement quietly pulls PC usage into scope. If you bought PPM alone and your users are creating change orders or working with the item master, you are almost certainly using PC, and Oracle will find it.
A PPM-only entitlement is one of the most common ways a full Product Collaboration finding lands on the table.
The reconciliation logic is mechanical. Oracle's License Management Services team, now operating under the GLAS brand, analyzes collected deployment and usage data, compares it against the entitlements in your contracts and purchase orders, and identifies the gaps. The deliverable is a formal audit report with quantities clearly tabulated. Note what the report does not contain: LMS does not present the financial details or the cost of resolution. It presents the licensing gap in units and instructs you to work with Oracle Sales. That split is deliberate. It separates the fact-finding (which looks technical and neutral) from the pricing (which is a sales negotiation) so the number that reaches you feels non-negotiable when it is anything but.
For each module found enabled and used, Oracle counts the users with access and calculates a NUP shortfall. Because Agile uses three user-license types (Named, Concurrent, and Restricted), the counting is where a lot of the inflation happens. Named users are not applied against concurrency counts and can log in at any time, while non-Named, non-Restricted users are subject to concurrency limits. Oracle will default to the most expensive reading of your population unless you have the records to prove otherwise. For external populations, our note on counting suppliers and external users in Agile PLM covers how Restricted-user status protects your distributor and supplier counts from being priced as full Named users.
The license shortfall itself is rarely the headline number. The financial teeth of an unlicensed-module finding is back-support. Remediation can include technical support fees for the entire period the unlicensed software was used, prorated back to when the license should have been initiated, at 22 percent or more of the license fees per year. Combine that with Oracle's retroactive-dating logic and the exposure balloons: if usage data shows a feature was first accessed three years ago, Oracle will claim you were unlicensed for three years and apply three years of retroactive charges.
Do the arithmetic on that. If a module finding is worth 500,000 dollars in net-new license, three years of back-support at 22 percent adds roughly 330,000 dollars before you have negotiated a single line. This is why Agile audits and GLAS reviews routinely land as six or seven-figure charges. The back-support multiplier, not the base license, is what turns a modest configuration slip into a material liability.
| Cost component | How Oracle calculates it | Buyer counter-position |
|---|---|---|
| Net-new license (module shortfall) | NUP users with access x per-user list price | Contest user counts; strip inactive and Restricted users |
| Back-support (annual) | 22%+ of license fees per year unlicensed | Challenge the first-use date; usage evidence, not deployment date, sets the clock |
| Retroactive dating | First feature-access date x years to present | Demand the actual access logs; do not accept an assumed start date |
| Prompt-payment deadline | 30 days from notice before daily accrual | Negotiate a standstill; do not sign under the 30-day clock |
Two deadlines matter for your planning. Customers are contractually required to resolve compliance gaps within 30 days of notice, and while the gap is unresolved, back-support can accrue daily. Oracle uses that clock as pressure. Do not treat it as a hard wall. In our experience the 30-day window is negotiable, and a standstill or extension is standard practice once you engage seriously. Signing a remediation quote to stop the clock, before you have validated a single figure, is the single most expensive mistake a buyer makes in an Agile review.
Module sprawl surfaces two ways: a formal LMS or GLAS audit, or a softer sales-led license review. The distinction matters. A license review by Oracle Sales can escalate into a full LMS audit if non-compliance is suspected, and both carry serious implications. The review is often the reconnaissance; the audit is the enforcement. If a sales rep starts asking friendly questions about how many people use your quality or portfolio functions, you are in a review, and you should treat every answer as evidence.
Oracle's account teams run periodic reviews, and an account that has not been audited in roughly three years or more is considered due for a check. If your Agile estate has been quiet, assume you are on a list. The correct response is to get ahead of it. A proactive self-review, run before Oracle makes contact, is the only reliable way to avoid the back-support multiplier, because it lets you disable unlicensed modules or true-up on your terms rather than under a formal notice. Our Agile PLM audit-defense evidence pack lays out exactly what to assemble before the letter arrives.
The correct response to a three-year-quiet Agile estate is a self-review, not a wait. You cannot un-see a finding once Oracle hands you the report.
The first move in any self-review is to reconcile what the Modules tab shows enabled against what your contracts and CSI actually grant. Pull your ordering documents, map each purchased module to a NUP quantity, then open the Licenses node in Agile and list every module set to Yes. Any module enabled but not on an ordering document is your exposure. This is a two-hour exercise that can save a seven-figure charge.
Remember the applications floor. Oracle applications carry a minimum order of a number of Named Users and months equal to 5,000 dollars, so even a small true-up has a floor. And remember that module licensing is phaseable: you can license only the required modules initially and add more later, which is a lever for both remediation scoping and any future expansion. For the full picture on how metrics, modules, and audit exposure interact across the product, start with our Oracle Agile PLM licensing buyer guide.
Oracle's own remediation menu is blunt: charge back-support for the period of unlicensed use, suspend technical support and updates, terminate the license agreement, or cancel partner and sublicense rights. In practice, two paths matter. Either you purchase sufficient licenses and support to cover the shortfall (with backdated support potentially assessed), or you remove the usage by disabling the module and proving it is no longer in use. The choice depends entirely on whether the module delivers business value worth the ongoing 22 percent annual support tail.
If a module is genuinely used and valuable, negotiate the purchase but fight the back-support aggressively on the first-use date and the user count. If a module was toggled on for a demo or a pilot and is not embedded in a business process, disable it and remove yourself from the exposure entirely. Where the whole Agile estate is stable and you are weighing the cost of Oracle support against alternatives, our analysis of Agile PLM on third-party support quantifies when leaving Oracle support pays. Never let Oracle frame the choice as purchase-only. Removal is always on the table for anything not load-bearing.
The net position after 25 years of these negotiations: Agile module sprawl is entirely preventable and largely negotiable, but only if you move before Oracle formalizes the finding. Enabled equals liable in Oracle's model. Audit your Modules tab, reconcile against your CSI, and price your own gap before Oracle prices it for you. The buyer who arrives at the table with their own reconciliation, their own user counts, and their own first-use dates controls the number. The buyer who reacts to Oracle's report pays the multiplier.
No. Oracle states explicitly that access to a license key file is not a grant of entitlement, and the keys do not technically enforce license restrictions. Enabling a module in the Modules tab makes it run, but your contract, not the software, defines what you are licensed to use. Any module set to Yes without a matching purchase order line is an exposure.
Oracle's LMS or GLAS team tabulates the license shortfall in Named User Plus units, then Oracle Sales prices it. The base license is only part of the number. Back-support at 22 percent or more per year, prorated back to first feature-access using Oracle's retroactive-dating logic, is usually the larger figure and can add years of charges before you negotiate.
Product Portfolio Management is the only Agile solution that can run without Product Collaboration, but Oracle's own documentation says a PPM-only company will likely still use PC. If your users create change orders or work with the item master, you are using PC. A PPM-only entitlement therefore often triggers a full PC finding.
Yes, if the module is not embedded in a live business process. Oracle's two remediation paths are purchase or removal. Disable the module, document the change date, and prove it is no longer in use. For anything not load-bearing, removal takes you out of the exposure entirely and is always negotiable alongside a purchase.
Contractually, 30 days from notice, with back-support accruing daily while the gap is unresolved. Oracle uses this clock as pressure. In practice a standstill or extension is standard once you engage. Do not sign a remediation quote to stop the clock before you have validated the user counts and first-use dates.
Export the Modules tab state, reconcile each enabled module against an actual purchase order line and your CSI, and pull active-user counts per module split by Named, Concurrent, and Restricted type. Any module enabled without an entitlement is your gap. Running this before an audit letter lets you true-up or disable on your terms.
Siebel is licensed on authorization across several user metrics, grants access through responsibilities and custom views, and sits under Oracle lifetime support. The traps and the
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
