Accidentally Enabled Security Options: The Audit Finding You Didn't Buy

One command can register Advanced Security, Label Security, or Database Vault in a table Oracle mines during every audit, and the resulting claim is backdated to the day a DBA touched it. This page shows where the metering happens, how to detect phantom usage before Oracle does, and how to defend the claim down to zero.

The mechanic that turns a keystroke into a six-figure claim

Oracle does not need to see you use a security option in production. It needs one row in DBA_FEATURE_USAGE_STATISTICS. That view records every separately licensed feature that has been invoked, along with the columns that matter commercially: DETECTED_USAGES, TOTAL_SAMPLES, CURRENTLY_USED, FIRST_USAGE_DATE, LAST_USAGE_DATE, AUX_COUNT, and FEATURE_INFO. During an audit, Oracle's LMS collection scripts sweep this view, treat any appearance as deployment, and price the option at full list across every processor in the server and across the entire window since FIRST_USAGE_DATE.

Read that last part again. Oracle calculates the claim from the first usage date, which is frequently years in the past because a DBA enabled a feature to test something, moved on, and never disabled it. You are not billed for the moment of the audit. You are billed retroactively for the full period the flag has been sitting there, plus backdated support at 22 percent per year on top. This is the single most common and most expensive category of Oracle audit finding, and it is entirely avoidable. Our Oracle Database security options licensing guide maps the full set of separately licensed features that behave this way.

Oracle prices the claim from FIRST_USAGE_DATE, not from the audit date. A ten-second command in 2021 becomes a four-year backdated bill in 2025.

Which security options meter, and what they cost when they do

Advanced Security (TDE plus Data Redaction), Oracle Label Security, and Database Vault all appear in DBA_FEATURE_USAGE_STATISTICS and are all swept during collection. Below is the list-price exposure per processor as of late 2025 and 2026. Note the wide published range on Database Vault. We have seen it quoted at both figures in different Oracle price references, and we flag that conflict below because it changes your negotiation math significantly.

The Advanced Security figure is stable across sources: $15,000 per processor, roughly $300 per Named User Plus, with the 25-users-per-core minimum in force. Database Vault is the outlier. One 2025 reference lists it at $11,500 per processor; a 2026 reference lists it at $47,500 per processor, describing it as Oracle's most expensive standalone database option. Do not accept either number on trust. Pull your own Oracle price list dated to the relevant period and hold Oracle to the price that was in effect on your FIRST_USAGE_DATE. For the head-to-head economics of these two options, see Oracle Label Security versus Database Vault.

To scale the exposure: a four-processor Enterprise Edition environment that touches TDE for a compliance requirement carries $60,000 in perpetual Advanced Security licenses plus $13,200 per year in support. On estates of 20, 50, or 100-plus processors, the perpetual figure runs from roughly $300,000 to $1.5 million, purely to legitimize a feature nobody deliberately bought. A fully optioned EE processor license reaches $122,000 at list with $26,840 in annual support, which is 2.6 times the base database license. The options, not the database, are where the money is. Our EE options pricing and audit-trap breakdown carries the full per-core math.

The one-touch traps that catch security-conscious DBAs

The cruel irony is that the DBAs most likely to trigger these flags are the ones doing security properly. Consider these documented traps:

• Privilege Analysis without Database Vault awareness. A DBA runs Privilege Analysis to tighten grants. That capability is a Database Vault licensed feature. The flag is set even if no realms, command rules, or enforcement were ever configured. Oracle can then claim full per-processor Database Vault for the entire capture period.
• Encrypted backups and exports. Creating an encrypted RMAN backup or an encrypted Data Pump export requires Advanced Security. This is a subtle metering path that many teams do not connect to a license, because they think of it as a backup operation, not a security option.
• Evaluation left running. In our review of Database Vault cases, evaluation enablement left a feature-usage flag in 30 to 45 percent of instances, which Oracle later cited as deployment. Turning a feature on to look at it is enough.
• The V$OPTION check. LMS scripts db_stat.sql and cpuq.sql read V$OPTION for enabled options. If DV_ENABLE_STATUS = TRUE and you have reported no Database Vault licenses, Oracle flags non-compliance regardless of whether the option is doing anything.

The underlying rule Oracle relies on is stated plainly in its own guidance: inadvertent use of options and packs is arguably the number one audit issue, and even a single command can flag usage. Oracle knows most customers do not lock these features down, and it prices its audit strategy accordingly. The accidental-use audit trap landing page catalogs the wider set of options that ship enabled or one click away.

The DBAs most likely to trigger a Database Vault claim are the ones running Privilege Analysis to make the estate safer. Good security hygiene becomes a phantom bill.

The partial-licensing trap makes the claim worse

When an option flag appears, you cannot minimize the damage by licensing only the cores or users that touched it. Oracle's rule is absolute: any server using Advanced Security must be fully licensed at the same scale as the database itself. Partial coverage (for example, two of four cores for TDE) is treated as a compliance gap, not a reduced obligation. If you licensed 16 processors of database but only 8 of Database Vault expecting partial coverage, Oracle claims the full 16. This is why a single tablespace encryption on one node of a large cluster can generate a claim covering every processor in that environment.

The practical consequence is that phantom usage on a big host is not a small problem. It scales with the host, not with the feature. Before you touch any security option, confirm the processor count and core factor of the machine it lives on, because that number, not your intent, sets the ceiling on the claim.

What Oracle no longer charges for (and where teams still overpay)

Two capabilities that DBAs still assume are chargeable have been free for over a decade, and Oracle rarely volunteers this during an audit conversation. Native network encryption and SSL/TLS, plus strong authentication services (Kerberos, PKI, RADIUS), were removed from Advanced Security from 10gR2 onward. Since June 2013, network encryption is licensed with Enterprise Edition and does not require Advanced Security. As of 19c, basic network encryption and TLS are included with EE outright.

So if an audit finding lumps network encryption into an Advanced Security claim, that portion is invalid and you should strike it. What Advanced Security still requires is TDE and Data Redaction on Enterprise Edition. Note that TDE is included and enabled by default in OCI managed services (Base Database Service, Autonomous Database), which is a different licensing world; the trap here is on-premises and BYOL EE. For teams meeting an encryption mandate, the right move is often to right-size around what EE already includes rather than buy the full option, a strategy we detail in meeting encryption mandates without overbuying.

How to detect phantom usage before Oracle does

You have more time than you think, and here is why. Oracle does not update DBA_FEATURE_USAGE_STATISTICS in real time. An internal MMON process checks which features have been used since the last check and runs once per week, typically on a Saturday. Any vendor tool claiming real-time feature-usage detection is misleading you: you can query the view every sixty seconds, but the numbers only change after the Saturday process completes. This weekly cadence is your detection and remediation window.

Run your own audit before Oracle runs theirs. The three reliable ways to read your position are covered in how to check Oracle license information, but for security options specifically:

• Query DBA_FEATURE_USAGE_STATISTICS directly for the Advanced Security, Label Security, and Database Vault rows. Record FIRST_USAGE_DATE, LAST_USAGE_DATE, DETECTED_USAGES, and CURRENTLY_USED for each.
• Cross-check V$OPTION for DV_ENABLE_STATUS and other option flags. This is what LMS reads, so read it first.
• Run the Oracle-provided options_packs_usage_statistics.sql, but treat its output skeptically. It has 14 documented bugs and does not filter false positives well.
• Do all of this weekly, aligned just after the Saturday MMON run, so you catch new flags within days rather than at audit time.

Defending the claim: separate detected from used, and hunt the false positives

An audit finding is an opening position, not a verdict, and the security-option category is the most challengeable of all because the data is noisy. Two documented false positives illustrate why you should never accept the raw view output. First, Oracle Enterprise Manager itself partitions its own repository tables, which registers Partitioning Option usage that is not your responsibility to pay for. Second, an unpublished bug (BUG 17164904, MOS Doc ID 1993134.1) caused over 700 detected uses of Advanced Compression in 12.1.0.1 because the compression counter incremented incorrectly for compression=metadata_only. The same class of counter and detection bugs affects security options.

Your defense checklist:

• Demand the raw evidence. Make Oracle show the specific rows and columns, not a summary. A claim citing 'usage detected' without DETECTED_USAGES, FIRST_USAGE_DATE, and FEATURE_INFO is not proof.
• Separate a flag from actual use. A single detected use with CURRENTLY_USED = FALSE and a first-and-last usage date on the same day is an evaluation or an accident, not a deployment. Argue it as such.
• Check the version against known bugs. If your flag sits on a release with a documented counter bug, cite the MOS document and require Oracle to prove genuine invocation.
• Strike the free components. Remove any network encryption or strong authentication from an Advanced Security claim. These have not required the option since 2013.
• Contest the backdating. Backdated support is a negotiation lever, not a fixed rule. In our experience it is routinely waived or reduced when the customer purchases forward or the usage is remediated.

For the full framework on reducing the number, including how to reframe the entire finding as an opening claim, see challenging Oracle audit findings. If the finding is part of a broader estate problem, the CIO playbook on option-pack rationalization covers the structural fixes.

What to do this quarter

Do not wait for an audit letter to discover a flag set in 2021. The actions below cost nothing but time and remove the most expensive line item in most Oracle audits before it can appear on a finding.

• Query DBA_FEATURE_USAGE_STATISTICS and V$OPTION across every EE database this week, and again every Saturday going forward.
• Where a security-option flag exists with no license, decide immediately: remediate (disable, and document the disablement date) or justify the purchase. Do not leave it ambiguous.
• Lock down feature access so DBAs cannot enable options by accident. Restrict the privileges that trigger TDE, Privilege Analysis, and Label Security policies.
• Confirm the processor count and core factor of every host running EE, because that number caps any future claim under the no-partial-licensing rule.
• Keep dated Oracle price lists on file so you can pin any claim to the list price in effect on the FIRST_USAGE_DATE, especially for Database Vault where published figures range from $11,500 to $47,500 per processor.
• If a flag is already several years old, engage before renewal, not during the audit, so backdated support becomes a negotiation item rather than a settlement demand.

Related advisory: the full topic guide.

Frequently asked questions

Does enabling Advanced Security once really create a permanent license liability?

It creates a row in DBA_FEATURE_USAGE_STATISTICS with a FIRST_USAGE_DATE that Oracle can cite as deployment. The liability is not automatically permanent, but Oracle will price the claim from that first date across every processor on the host. Disabling the feature and documenting the date is your remediation path, but the flag itself remains in the view, so keep evidence that usage stopped.

How quickly does Oracle detect that I used a security option?

Not in real time. The internal MMON process that populates the feature-usage view runs once per week, typically on a Saturday. You will not see a new flag, and neither will an audit script reading the view, until that weekly job completes. This gives you a detection and remediation window of a few days if you monitor after each Saturday run.

Can I license only the cores that touched TDE instead of the whole server?

No. Oracle's rule requires any server using Advanced Security to be fully licensed at the same scale as the database. Partial licensing, such as covering two of four cores, is treated as a compliance gap and Oracle will claim the full processor count. This is why a single encryption command on a large host can generate a claim covering every core.

How much is Database Vault, given the conflicting figures?

Published sources conflict sharply: one 2025 reference lists $11,500 per processor, while a 2026 reference lists $47,500 per processor. Do not accept either on trust. Pull the Oracle price list dated to your FIRST_USAGE_DATE and hold Oracle to the price in effect at that time, because a factor-of-four difference changes your entire negotiation position.

Is network encryption part of the Advanced Security license?

Not since 2013. Native network encryption, SSL/TLS, and strong authentication (Kerberos, PKI, RADIUS) were removed from Advanced Security and are included in all licensed editions of supported releases. If an audit finding bundles network encryption into an Advanced Security claim, that portion is invalid and you should strike it.

Can feature-usage data be wrong?

Yes, and it frequently is. Oracle Enterprise Manager partitions its own tables and registers Partitioning usage that is not your liability, and documented bugs such as BUG 17164904 caused hundreds of false Advanced Compression detections. Always demand the raw rows, check your release against known bugs, and separate a single evaluation flag from genuine ongoing use before accepting any number.