Oracle database licensing

Oracle Advanced Security Licensing

Oracle Application Express License

Oracle Advanced Security Licensing

Oracle Advanced Security Licensing is a critical topic for enterprises using Oracle Database.

This advisory provides IT Asset Management (ITAM) professionals with a clear understanding of the Oracle Advanced Security Option โ€“ what it is, how itโ€™s licensed, and how to manage it for compliance and cost-efficiency.

In short, Advanced Security is a separately licensed add-on for Oracle Database Enterprise Edition that enables encryption and data protection features.

Proper licensing and proactive management are crucial to meeting audit requirements and avoiding costly compliance pitfalls.

Understanding Oracle Advanced Security Option

Oracle Advanced Security is an add-on for Oracle Database Enterprise Edition (EE) that provides enhanced data protection capabilities.

It primarily addresses the need to protect sensitive data at rest and in transit, enabling organizations to meet stringent security and privacy requirements.

Key features of the Advanced Security Option include:

  • Transparent Data Encryption (TDE): Encrypts data at rest in the database โ€“ at the column level or entire tablespaces โ€“ so that stored data is unreadable without decryption keys (protecting against data theft from files or backups).
  • Data Redaction: Dynamically masks or obfuscates sensitive data in SQL query results based on user roles/policies, ensuring that applications only reveal whatโ€™s permitted.
  • Backup and Export Encryption: Encrypts database exports (Data Pump files) and backups (RMAN backups) to secure data outside the live database environment.
  • Advanced Network Encryption (historical): Encrypts data in transit over SQL*Net. (Note: As of Oracle 19c, basic network encryption and TLS are included with EE, so these no longer require the Advanced Security license for current versions.)
  • Strong Authentication Integrations: Enables the use of enterprise authentication methods, such as Kerberos, RADIUS, PKI certificates, or smart cards, with the database, extending beyond the default username/password.

Why enterprises use it:

Advanced Securityโ€™s encryption and redaction capabilities are often necessary for regulatory compliance (e.g., GDPR, HIPAA, PCI-DSS) and for protecting intellectual property.

By deploying TDE and related features, organizations can ensure that even if unauthorized parties access database files or backups, the data remains protected.

However, using these features comes with licensing obligations that enterprises must carefully manage.

When and Why You Need an Advanced Security License

Oracle Advanced Security must be licensed whenever its features are used โ€“ it is not included in the standard database license.

In practice, you need this license if you enable any of the following in an Oracle Database Enterprise Edition environment:

  • Transparent Data Encryption: If you encrypt any part of the database (columns, tablespaces, or the entire database) using TDE, that database requires an Advanced Security license. Even a single encrypted table or column triggers this requirement.
  • Encrypted Backups or Data Pump Exports: Utilizing Oracleโ€™s encryption for backups (via RMAN) or export files means youโ€™re leveraging Advanced Security functionality; therefore, a license is required for the databases where this is performed.
  • Data Redaction Policies: Implementing data redaction (masking out sensitive data in query outputs) in the database requires licensing Advanced Security for that database.
  • Integration with External Key Managers or Strong Authentication: If you integrate the database with an external key management system (for TDE key storage) or enable Kerberos/RADIUS authentication for users, these fall under Advanced Security features and require licensing.

Itโ€™s important to note that Oracle does not automatically prevent you from using these features without a license โ€“ the software allows activation, but Oracleโ€™s audit scripts will capture any usage.

During an audit, Oracleโ€™s License Management Services will detect features such as TDE or Data Redaction being used and expect you to provide proof of sufficient licenses (or else pay for them).

Even if such features were enabled accidentally or for a short time, it can still be considered usage. Therefore, ITAM professionals should closely monitor and control the use of Advanced Security features to avoid unwittingly incurring license liability.

What doesnโ€™t require Advanced Security:

Basic data security features that come with Enterprise Edition do not need this add-on. Notably, from Oracle Database 19c onward, native network encryption and TLS support are included with EE at no extra cost.

Earlier versions required Advanced Security for network encryption, but this requirement was later removed, allowing for free inclusion in 19c and later versions.

Similarly, standard password authentication and basic security features of the database remain covered under the base EE license.

The Advanced Security Option specifically addresses the advanced encryption, redaction, and external authentication integration capabilities listed above.

Licensing Metrics and Pricing

Oracle Advanced Security is licensed in the same way as the Oracle database itself โ€“ you must use the same metric (and quantity) as your Database Enterprise Edition license for any given deployment.

There are two metrics available: Processor and Named User Plus (NUP). The choice typically mirrors how youโ€™ve licensed the database:

  • Processor Licensing: Count the physical processor cores (with Oracleโ€™s core factor) on the servers where the Oracle database is running. If your database EE is licensed per processor, you must purchase the Advanced Security option for every processor core that the database utilizes. For example, suppose an Oracle EE database is running on a server with eight cores (and assuming a core factor of 1.0 for simplicity). In that case, youโ€™d need eight processor licenses of Oracle Advanced Security for that server. Processor-based licensing allows unlimited user count, but every core must be covered.
  • Named User Plus Licensing: Count the number of distinct users (including humans and devices) that access the Oracle database. Suppose your database EE is licensed on a Named User Plus basis. In that case, the Advanced Security licenses must equal or exceed the same user count (with Oracleโ€™s standard rule of at least 25 Named User Plus per processor as a minimum). For instance, on a 4-core database server, Oracle requires at least 4 ร— 25 = 100 Named User Plus licenses as a minimum, even if the actual number of users is fewer. If you have more than the minimum, you must license the actual number of users. This model can be cost-effective if you have a controlled, small user population per processor.

Matching metrics: Itโ€™s a strict Oracle policy that you cannot mix metrics for the database and its options on the same environment. For example, if your database is licensed per processor, you cannot attempt to license Advanced Security by NUP (or vice versa) for the same server โ€“ both licenses must align.

Additionally, the quantity of licenses must match the scale: you cannot partially license some processors or a subset of users for this option.

Any server that utilizes Advanced Security features must be fully licensed, just like the database. Partial licensing (e.g., only licensing two cores out of a 4-core server for TDE use) is not permitted and would result in a compliance gap during an audit.

Pricing: Oracle Advanced Security is a high-value option and is priced accordingly. The list price (as of 2025) is $15,000 per processor license for the Advanced Security Option. For Named User Plus, the list price is approximately $300 per user (with the 25-user-per-core minimum in effect).

Annual support maintenance accounts for approximately 22% of the license fee per year. This means each Advanced Security processor license also carries an ongoing support cost of about $3,300 per year if you maintain Oracle support.

To put it in context, the Advanced Security Optionโ€™s cost is about one-third of the Oracle Database EE base license (which is $47,500 per processor).

For example, licensing a single 8-core server for Oracle EE plus Advanced Security (at list price) would run:

LicenseMetricList Price (USD)Notes
Oracle Database Enterprise Edition (EE)Per Processor$47,500 per processorBase database license (per-core pricing). Named User Plus also available at $950 per user (25 minimum per core).
Oracle Advanced Security Option (ASO)Per Processor$15,000 per processorAdd-on option for encryption/redaction. If licensed by NUP, ~$300 per user (25 minimum per core). Must match EE licensing metric and quantities.
Annual Support (software update license)Perpetual licenses22% of license price annuallyYearly support contract for updates and support. E.g., ~$10,450 per processor/year for EE, and ~$3,300 per processor/year for ASO.

The above are Oracle list prices; many enterprises negotiate discounts. However, these figures illustrate that deploying Advanced Security can significantly increase the cost of an Oracle environment (roughly adding ~30% on top of the database license cost per processor, before discounts). Itโ€™s vital to budget for both the upfront license and ongoing support when planning to use this option.

Cost Drivers and Optimization Strategies

The cost of Oracle Advanced Security can scale quickly in a large enterprise, but there are ways to manage and optimize it.

Key cost drivers to be aware of include:

  • Number of Processors and Environments: Every database instance that utilizes Advanced Security features requires licensing. More databases or servers = more licenses. This includes production, testing, development, disaster recovery โ€“ all environments count if the feature is enabled. (Oracle does not provide free non-production use except for very limited developer licenses tied to individual use.)
  • Processor Core Counts: The higher the core count of your servers, the more processor licenses required. Oracleโ€™s core factor table can slightly reduce counts for certain processors (e.g., some Intel chips have a 0.5 factor); however, generally, more CPU cores result in higher costs. Some organizations optimize by consolidating databases on fewer servers or utilizing hardware with a favorable core count to reduce license costs.
  • User Counts (if NUP): If you license by Named User Plus, the total number of named users accessing those databases drives the cost. Be cautious with user counting โ€“ include application service accounts and all indirect users. If user counts rise, costs may spike or necessitate moving to processor licensing.
  • Annual Support Fees: Over a typical multi-year period, support fees often exceed the original license cost. At ~22% per year, in under five years, you effectively pay the license cost again in support. This should be factored into ROI calculations for encryption projects.
  • Compliance Penalties: Although not a direct cost driver in planning, itโ€™s worth noting that non-compliance can be extremely expensive. Suppose Oracle audits your company and finds Advanced Security features in use without licenses. In that case, the penalty will typically involve buying licenses at list price plus back-support for the entire period of unlicensed use (and possibly fines). This โ€œunplanned costโ€ can dwarf the cost of proactive licensing, making compliance the more cost-effective path.

Optimization strategies:

  • Scope Control: Use Advanced Security only where itโ€™s truly necessary. Identify which databases handle regulated or highly sensitive data that justifies encryption. Not every database in the estate may require TDE or redaction. By limiting deployment of these features to specific systems, you can limit the number of licenses required.
  • Alternatives for Lower-Tier Systems: For databases that donโ€™t justify the cost but still require some protection, consider alternatives such as operating system or storage-level encryption (e.g., disk encryption, file-system encryption, or database-level encryption in Standard Edition through third-party tools). These alternatives might not be as granular or integrated as Oracleโ€™s TDE, but they can provide basic at-rest protection without violating Oracle licenses (since they donโ€™t use Oracleโ€™s feature). Always ensure any alternative approach meets your security requirements and is supported.
  • Consolidation and Architecture: Evaluate your architecture โ€“ it may be cost-effective to consolidate multiple databases that require encryption onto a single, licensed platform (if feasible from a performance/isolation standpoint) rather than spreading the encrypted data across many separate servers. Fewer licensed servers or instances can reduce total license count. Conversely, avoid accidentally sprawling encrypted data onto additional servers, which would then all require licensing.
  • Enterprise Agreements: If your organization has broad encryption needs, negotiating an Enterprise Agreement or Unlimited License Agreement (ULA) that includes Advanced Security could be a cost-effective solution. In a ULA, you pay a fixed fee for unlimited use for a period. This can cover Advanced Security across many servers without per-core counting (until the ULA ends). However, be very careful: ensure that Advanced Security is explicitly included in any such agreement. If not, using it under a false assumption of coverage would be a compliance problem.
  • Stay Current on Versions: Since Oracle has moved some features (like network encryption) into the free category in newer versions, upgrading databases to current releases can eliminate the need for a license for certain capabilities. This doesnโ€™t remove the cost for TDE or data-at-rest encryption, but it means you donโ€™t have to spend on the option just for securing data in transit, for example. Leverage all the security functions that come with the base license first.

By combining these strategies โ€“ deploying only where needed, exploring alternatives, optimizing infrastructure, and leveraging Oracle agreements wisely โ€“ enterprises can minimize the cost impact of Oracle Advanced Security while still achieving their security and compliance objectives.

Managing Compliance: Audits and Entitlements

Oracle Advanced Security is often in Oracleโ€™s audit spotlight because itโ€™s both commonly required (for compliance) and commonly overlooked in licensing.

To avoid unpleasant surprises, ITAM teams should take a proactive stance on compliance, both by monitoring usage and maintaining accurate entitlement records.

Know your entitlements:

First, inventory what Oracle licenses your organization owns. This involves collecting all Oracle ordering documents, license certificates, and contract schedules to confirm whether you have purchased Advanced Security Option licenses and, if so, the quantity.

Keep track of the metric (NUP or processor) and any contractual limitations that apply. For example, you might have acquired some ASO licenses as part of a bundle or migration deal โ€“ be aware of where those apply.

Itโ€™s not uncommon for companies to lose track of what theyโ€™ve bought over the years, especially after mergers or personnel changes.

Maintaining a central repository of Oracle entitlements (including Advanced Security and other database options) ensures you know your starting point.

Monitor feature usage: Oracle provides views and audit scripts to help detect usage of licensable features. A crucial one is DBA_FEATURE_USAGE_STATISTICS Within each database, which logs usage of features such as TDE and Data Redaction.

Regularly review this (or run Oracleโ€™s LMS collection tool in a read-only mode) to see if any Advanced Security features show up as used in any instance.

This is especially important because DBAs or security teams might enable encryption without routing the request through licensing management.

By catching it internally, you can decide to either disable the feature or procure the necessary license before Oracleโ€™s auditors do.

Internal audits: Conduct periodic internal license audits focusing on Oracle Database options. This means checking every environment where Oracle Database EE is deployed and verifying:

  • Are any Advanced Security features enabled or configured? (Check for encryption keys/wallets present, initialization parameters related to encryption, existence of redaction policies, etc.)
  • If yes, do we have sufficient licenses allocated to that environment?
    Perform this check at least annually or before any expected Oracle audit or contract renewal. Itโ€™s far better to discover a shortfall yourself and rectify it (or at least plan for it) than to have Oracle find it.

Audit preparedness:

If Oracle notifies you of a license audit (or during routine true-ups), be ready to demonstrate control. This includes having documentation of all Advanced Security deployments and the corresponding licenses.

Demonstrate your understanding of which databases utilize encryption and that they are properly licensed. Itโ€™s also wise to remediate any non-compliant usage before an official audit begins.

For instance, by disabling Advanced Security features on a non-critical instance that wasnโ€™t licensed, or by purchasing additional licenses if needed. Oracle auditors appreciate when customers have clear records; it can make the process smoother and reduce suspicion of broader compliance issues.

Donโ€™t ignore development and DR environments:

A common mistake is assuming that non-production instances donโ€™t need licenses (โ€œWe only turned on TDE in test, so it doesnโ€™t count.โ€).

Oracleโ€™s policy is unambiguous: if the software is installed and the option is used, a license is required regardless of the environment. The only exception is if you are using Oracleโ€™s free developer license for purely internal, non-production development by a single developer.

However, this license cannot be used for multi-user test or staging environments, and it doesnโ€™t cover production data encryption. Also note Oracleโ€™s โ€œ10-day ruleโ€ for disaster recovery. If you open a standby database for more than 10 days a year for purposes other than an actual failover, it may require full licensing (and if that standby has TDE enabled, that counts too). Always factor in all instances in your license count.

Keep contracts and documentation handy:

Ensure that all proof of license entitlements (contracts, ULA certificates, support renewals that list quantities) are organized. During an audit or even an internal review, youโ€™ll need to match usage to entitlements.

For example, if you claim you have 10 processor licenses for Advanced Security, you should be able to pull up the document showing that purchase.

This also helps in discussions with Oracle โ€“ if you detect any Advanced Security usage that youโ€™re not licensed for, you may be able to negotiate a purchase or a deal with Oracle before they audit you, potentially at better prices than after an audit.

In summary, treating Oracle Advanced Security like any other asset is key: track what you own, monitor how itโ€™s used, and educate your technical teams about the dos and donโ€™ts.

Combining vigilant internal governance with proper record-keeping will significantly reduce audit risk and ensure your organization remains compliant while utilizing these critical security features.

Recommendations

Practical Tips for Managing Oracle Advanced Security Licensing:

  • Educate Your Team: Make sure database administrators and security engineers understand that Advanced Security features (like TDE, Data Redaction) are not โ€œfreeโ€ with Oracle Database. Provide them with clear guidelines on which features are licensed separately. This prevents well-intentioned but unlicensed use.
  • Enable Controls to Prevent Accidental Use: Utilize Oracle Database controls. For example, you can set database initialization parameters or use Oracleโ€™s feature usage control to disable options youโ€™re not licensed for. Proactively disabling Advanced Security Option in databases where itโ€™s not licensed can stop accidental activation.
  • Regularly Audit Your Oracle Environments: Perform routine internal audits or use Oracleโ€™s scripts to check for usage of Advanced Security features. Catching a feature usage early allows you to take action (license it or turn it off) before it becomes a bigger compliance issue.
  • Align Licensing with Deployments: Ensure that whenever your organization implements encryption or other Advanced Security capabilities in a new database, the licensing team is involved. Integrate a licensing check into change management for any Oracle database that will have TDE or similar features enabled. This way, the procurement of licenses (or allocation from an existing pool) occurs in tandem with technical deployment.
  • Keep an Entitlement Inventory: Maintain an up-to-date inventory of the number of Advanced Security licenses you own and how they are allocated (to specific servers or user counts). This helps you avoid both under-licensing and over-licensing. You may discover, for instance, that you have spare licenses from a decommissioned system that could cover a new encryption deployment.
  • Consider Enterprise License Options: If your company anticipates heavy use of Advanced Security across multiple systems, discuss enterprise licensing options with Oracle. A ULA or campus/license pack that includes Advanced Security may provide cost savings if negotiated effectively. Always weigh the fixed cost vs. your projected usage to ensure itโ€™s a good deal.
  • Leverage Oracle Cloud for New Workloads: If youโ€™re moving workloads to Oracle Cloud (OCI), note that Oracleโ€™s autonomous database services include encryption by default without you needing separate Advanced Security licenses. For new projects, using a cloud service with a โ€œlicense includedโ€ option can sidestep on-premises license management. (BYOL โ€“ bring your license โ€“ is also an option, but then you must bring the Advanced Security licenses too.)
  • Prepare for Audits in Advance: Donโ€™t wait for an official audit letter. Have a clear action plan for Oracle audits: identify who in your organization will gather data, ensure you have recent usage reports ready, and consider engaging external licensing experts to verify your compliance stance. Preparation can turn an audit from a fire drill into a more routine verification exercise.
  • Avoid Last-Minute Scrambles: Plan your security and compliance needs well ahead. If you know a certain application will require database encryption next year, start budgeting and purchasing for Advanced Security now (or negotiating it into an agreement) rather than enabling TDE first and scrambling for licenses later. Oracle sales teams are more flexible before youโ€™re out of compliance than after the fact.

Checklist: 5 Actions to Take

For ITAM professionals looking to ensure compliance with Oracle Advanced Security licensing, hereโ€™s a simple step-by-step plan:

  1. Inventory All Oracle Databases and Features โ€“ Scan your environment to identify every Oracle Database instance and check if Advanced Security features (TDE, Data Redaction, encrypted backups, etc.) are in use. Use Oracleโ€™s feature usage statistics or scripts to flag any usage of these features. Document which databases have them enabled.
  2. Verify License Entitlements vs. Usage โ€“ Gather your Oracle licensing agreements to find out how many Advanced Security licenses you own (processors or NUP) and compare against the usage identified. For each database using Advanced Security, ensure that you have allocated enough licenses. If there are gaps โ€“ usage with no licenses โ€“ mark those for remediation.
  3. Remediate Non-Compliance โ€“ Take immediate action on any unlicensed usage. Options include purchasing additional licenses to cover usage, temporarily disabling the Advanced Security features on that database until licensed, or migrating the databaseโ€™s data encryption needs to an alternative solution if appropriate. Coordinate with the DBA and security team to implement the solution and track it to completion.
  4. Implement Governance Controls โ€“ Establish policies or technical controls to prevent future unauthorized use. For example, update your database provisioning checklist to include a license review before enabling encryption. Configure monitoring to send alerts if someone creates an encrypted tablespace or redaction policy on an unapproved system. Establish a governance board or include ITAM in change management for database security features.
  5. Ongoing Monitoring and Audit Prep โ€“ Make it a routine (quarterly or semi-annually) to review Advanced Security usage and license compliance. Keep a log of any changes (new databases with encryption, license purchases, etc.). Simulate an Oracle audit internally: ensure you can quickly retrieve evidence of licenses and usage for Advanced Security. By staying audit-ready and regularly updating your records, youโ€™ll avoid last-minute surprises and demonstrate strong license management if Oracle comes knocking.

FAQ

Q: Is Transparent Data Encryption (TDE) included in Oracle Database Enterprise Edition by default?
A: No. TDE is not included with the base Enterprise Edition; it requires the Oracle Advanced Security Option license. Unless you have specifically licensed Advanced Security (or are using an Oracle cloud service that includes it), you are not entitled to use TDE in an Oracle database. Always treat TDE as a separately chargeable feature in on-premise deployments.

Q: What exactly does an Oracle Advanced Security license cover?
A: An Advanced Security license gives you the right to use all features under that option for one database instance (if by processor, for all cores of that server; if by NUP, for the covered users). This includes Transparent Data Encryption (tablespace, column, or full database encryption), Data Redaction, Data Pump export encryption, RMAN backup encryption, integration with external key managers, and strong authentication services (such as Kerberos). Itโ€™s essentially a bundle โ€“ one license per unit (processor or user) covers all these features on a given database. There isnโ€™t a separate license for each sub-feature; itโ€™s all or nothing under the Advanced Security Option.

Q: Do we need to license Advanced Security for non-production (dev/test) databases?
A: Yes, if those environments use the Advanced Security features. Oracleโ€™s licensing applies to any use of the software, regardless of whether the database is in production, test, or development use. The only exception is individual developer use under the free OTN Developer License (which is limited in scope and not for general test environments or multi-user access). For example, if you enable TDE on a QA database with Enterprise Edition, that QA database must be licensed for Advanced Security, just like production. Companies should budget licenses for at least the key non-production instances that will mirror productionโ€™s security features (or ensure those features remain off in test if they want to avoid the cost).

Q: Oracle database 19c and later include native network encryption for free โ€“ what does that mean for Advanced Security?
A: It means that as of 19c, you do not need to purchase Advanced Security just to encrypt data in transit. Oracle now allows you to configure native network encryption (using AES protocols for SQL*Net traffic) and TLS/SSL encryption for database connections as part of the base product. Previously, these capabilities were part of the Advanced Security Option, but they have since been integrated into the included features. This change is great for security-conscious customers because it allows you to secure data in motion without incurring extra licensing costs. However, encryption of data at rest (TDE) and data redaction still require Advanced Security licenses. So while network encryption is free, youโ€™ll still need the Advanced Security Option for full data-at-rest protection.

Q: What happens if we are audited by Oracle and found using Advanced Security features without licenses?
A: In an audit, Oracle will likely present you with a formal compliance report showing the usage of Advanced Security features and a shortfall in licenses. The resolution typically involves purchasing the required licenses (at list price) for all the cores or users that were using the option, potentially backdated to when the usage began. Oracle may also charge back-support fees for those lapsed periods (to cover the cost of support that would have been incurred had you been licensed then). There may be room for negotiation, but the cost can be substantial โ€“ often much higher than if the licenses were acquired proactively with a discount. Additionally, youโ€™ll be expected to rectify the situation immediately (either by disabling features or purchasing sufficient licenses). Itโ€™s a scenario every enterprise wants to avoid. Thatโ€™s why we emphasize internal auditing and compliance: detecting and licensingย Advanced Security usage in advanceย is far less expensive and less contentious than addressing it during an official audit.

Read more about our Oracle License Management Services.

The #1 Global Oracle Licensing Experts โ€“ Redress Compliance

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.
Name
Author
  • Fredrik Filipsson

    Fredrik Filipsson is the co-founder of Redress Compliance, a leading independent advisory firm specializing in Oracle, Microsoft, SAP, IBM, and Salesforce licensing. With over 20 years of experience in software licensing and contract negotiations, Fredrik has helped hundreds of organizationsโ€”including numerous Fortune 500 companiesโ€”optimize costs, avoid compliance risks, and secure favorable terms with major software vendors. Fredrik built his expertise over two decades working directly for IBM, SAP, and Oracle, where he gained in-depth knowledge of their licensing programs and sales practices. For the past 11 years, he has worked as a consultant, advising global enterprises on complex licensing challenges and large-scale contract negotiations.

    View all posts

Redress Compliance