If you already run Audit Vault and Database Firewall and just found out Oracle now calls something “Database Security Central,” this post answers the question you probably have first: is this a new thing to buy, or is it what AVDF becomes? Since this question tends to come with two more attached to it, I will also walk through exactly how you get from AVDF to Security Central, where you can actually run it, and how it sits next to Oracle Data Safe, because those are the three things that decide what you do next.
I will start by describing what Database Security Central actually is in concrete terms, because the name does not say much. Then I will lay out, point by point, what genuinely changes. I will keep this as plain as I can, because a security platform that keeps its own vocabulary is the kind that ends up unused.
What Database Security Central actually is
Strip away the name and Database Security Central is a preconfigured software appliance that you install and operate, much like the Audit Vault Server you already run. It is not a managed service that Oracle hosts on your behalf. You deploy the appliance on bare metal or virtual machines on-premises, or you deploy the Oracle-provided image in OCI, or on other clouds. It reaches your databases and other sources through agent, agentless, and proxy collection models, and it supports the full range of deployment patterns you would expect: Exadata, RAC, and Data Guard.
So the first question – “is it on-prem software, an OCI service, a multicloud service?” – has a clear answer: it is the same class of product as AVDF. You host it. Oracle supplies the appliance and the images.
One scope point is worth stating early, because it changes how you size the value. Database Security Central is not limited to Oracle databases. It collects from Oracle and non-Oracle estates in the same deployment, including MySQL, Microsoft SQL Server, Db2, PostgreSQL, Sybase, and MongoDB.
What the appliance now bundles “on top of” the activity-monitoring foundation is a broader set of capabilities – already present in ADVF -, which now Oracle packages as “360” views:
- User360 – identifies privileged and high-risk users, maps the direct and indirect role and privilege graphs, and surfaces dormant accounts and entitlement drift over time.
- Data360 – discovers and classifies sensitive data across production, test, development, and reporting environments, working from both table metadata and actual row data to reduce false positives and false negatives, with 181 predefined sensitive types across 20 categories plus custom types you can add.
- Configuration360 – assesses posture across the fleet from a baseline of 132 risk findings across 7 categories at 6 risk levels, detects configuration drift continuously, surfaces missing patches and known CVEs, and lets you schedule recurring assessments and attest the results.
- Audit360 – the activity auditing, out-of-the-box reporting, SIEM/BI integration, and policy-based alerting that AVDF users already know.
Around those views sit two things that are the real reason of this evlolution. The Security Control Center correlates signals from user access, sensitive data, configuration posture, and activity into one prioritized risk view, so a finding like “a high-risk user has access to sensitive data on a drifted system” rises to the top instead of living on a separate screen. Unified Policy Management moves policy authoring from per-target configuration to a single console from which audit, alerting, Database Vault, Database Firewall, and SQL Firewall policies are created, reviewed, and deployed across the fleet. A natural-language AI Advisor adds on top, letting teams query posture and draft alert conditions – a mode of interaction that has no equivalent in AVDF.
The value of correlation is really useful. User360 finds a dormant administrator who has not logged in. Data360 shows that same account can reach personally identifiable data in two databases. Policy management shows there is no alert on that access path. Three point tools would file three separate tickets, or none at all. Security Central joins those signals into a single ranked finding – a dormant admin with a live path to sensitive data – and attaches the next action: review the account, set the alert, verify the policy. That join, rank, and act step is what fragments cannot do.
AI-assisted analysis compresses what used to take weeks of attack planning into days, and fully automated attacks into hours. The platform is shaped so that the visibility side closes that gap at fleet scale rather than database by database.
The appliance itself is powered by Oracle RAC for horizontal scalability and high availability, uses AES-256 encryption for data at rest and TLS 1.3 for the management and collection plane, and is positioned as quantum-ready (I talked about this already in a previous post).
It extends AVDF; it does not replace it
This is the question you asked, so I will answer it clearly. Oracle’s concepts guide states it directly: for an existing AVDF customer, the move to Database Security Central is an extension rather than a replacement.
What that means in practice is that the things you have already built carry forward. Your audit collection infrastructure, your firewall deployments, your compliance reports, your alert configurations, and your data retention policies are not discarded. Oracle’s framing is that the capabilities you rely on today are the operational foundation of the new platform, and Security Central adds a broader security surface on top of that foundation.
AVDF is now a restricted product and is not available for general purchase, so new deals are positioned as Security Central. And AVDF 20.x remains under Premier Support until May 2027, after which it moves to Sustaining Support. That is the window within which Oracle expects existing customers to plan their transition, and it lines up neatly with the no-cost period for Security Central, which I will get to when we talk about the path.
From AVDF to Security Central: the actual path
It is a platform transition, not a version upgrade. Oracle provides an out-of-place upgrade path that is designed for a controlled transition with minimal disruption. The word that matters here is out-of-place: you do not upgrade the Audit Vault Server in place. You build a new destination server for Security Central on a separate machine, migrate the data and configuration over, and then reconnect your estate. The original AVDF 20 system stays available throughout, which is what gives you a clean fallback if anything needs to be revisited.
To use the upgrade path you need AVDF 20.14 or later as your source, running the 19c (non-CDB) model that AVDF 20.x uses. The destination is Security Central on a 26ai database, structured as a container database with the Audit Vault Server running on a pluggable database. If you are below 20.14, the first step is to bring the AVDF server up to a supported 20.14+ release before the migration.
Oracle documents three paths, depending on your current topology:
- Standalone AVDF 20.x to standalone Security Central.
- AVDF 20.x with a standby to Security Central with a standby – you prepare the Security Central standby before the cutover, synchronize it, and complete the post-standby migration.
- RAC configuration after the upgrade. RAC is not part of the out-of-place migration itself; you configure it once the standalone Security Central server is up.
The migration is deliberately structured so that the long work happens while production monitoring is untouched:
- Prepare (no downtime). You build the destination on a separate machine with hardware that is at least as good as the source and roughly 15% more total storage than the AVDF server. Agents and Database Firewalls must be able to reach both the source and the destination, archive locations that are currently SCP or SMB are moved to NFS, and you install the migration software and take a backup. During this whole phase the source AVDF 20 keeps monitoring.
- Migrate (the downtime window). The cutover starts when you stop monitoring on the source. You then isolate the source, run the data and configuration migration plus the system upgrade, and apply the application upgrade on the destination. This is the only phase that takes databases and monitoring offline.
- Post-migrate (reconnect the estate). Agents are auto-updated and reconnected to the destination (a matter of minutes per agent), and the Database Firewalls are upgraded in place and re-pointed at the new server with updated certificates. You then start trails and monitoring points and verify that every agent and firewall is connected and online.
The key recovery property is that, at any point before the post-migrate phase is complete, you can fall back to the AVDF 20 source and resume monitoring there. You are not forced to bet the whole estate on a single cutover.
So this is a designed, reversible, out-of-place platform transition with a known prerequisite, documented scenarios, and a fallback – not a big-bang in-place upgrade.
Where you can run it: on-premises, OCI, and multicloud
Database Security Central is a customer-managed, preconfigured appliance designed for consistent deployment, and Oracle documents it as available in OCI through the OCI Marketplace, where it is provisioned as an Oracle-provided offering. Beyond OCI, the same appliance class is deployed by you on on-premises hardware or virtual machines, and it is also documented as installable on other clouds, including AWS, Azure, and Google Cloud. So yes, Oracle publishes and supports running it in OCI (as a Marketplace offering), and the appliance model is explicitly built to run in OCI and to reach databases across on-premises and multicloud estates.
The distinction that is easy to blur is between where the appliance runs and what it can see. The appliance itself is a customer-managed server you deploy and its operational visibility is explicitly across on-premises, cloud, and multicloud environments – which is the point of a fleet command center. It collects from databases that are in OCI, in third-party public clouds, and on-premises through the same agent, agentless, and proxy models, and it gives you one correlated risk and policy view across all of them.
One personal recommendation: because feature availability can vary by target platform, confirm the supported capabilities and versions in the current product documentation before you commit to a specific design, rather than assuming every feature is available in every deployment target.
What about Oracle Data Safe?
It seems to me that the two products – Security Central and Datasafe – genuinely overlap on a set of controls. So lets analyze where they meet and where they differ.
What they share. Both Oracle Data Safe and Database Security Central work the same underlying risk questions across an Oracle estate. Both do security assessment – identifying, categorizing, and prioritizing configuration risks and drift, with findings mapped to the same reference set (GDPR, DISA STIGs, CIS benchmarks). Both do user assessment – finding overprivileged, risky, and dormant users. Both do sensitive-data discovery and classification from a library of predefined sensitive types extended with custom ones. And both are involved with SQL Firewall, the allow-list control built into Oracle AI Database 26ai that learns normal application behavior and blocks deviations.
Where they differ is the operating model. Database Security Central is a customer-managed appliance that you deploy and operate. Oracle Data Safe is a managed, cloud-native service – a control plane you consume rather than a server you run. That single fact drives the rest.
Do they compete? Not really – they are two deployment postures for the same control family. The honest framing is that Oracle has aligned both products around a common set of database-security controls (posture, user risk, sensitive data, SQL Firewall, compliance) and offered them in two shapes: a customer-managed appliance (Security Central, extending the AVDF investment you already have) and a managed cloud service (Data Safe, which you consume and which adds data masking and long audit retention). They share controls rather than fight over them.
When does it make sense to use one, the other, or both?
- Use Security Central when you want to extend an existing AVDF deployment, when you need the network-level Database Firewall, when you want customer control of the security management plane and the audit data (which matters for regulated European estates that care about where that data physically lives), or when you are standardizing on a single fleet appliance you operate yourself.
- Use Data Safe when you prefer a managed, cloud-native control plane for Oracle databases – especially Autonomous AI Database, Exadata Cloud Service, and databases across OCI, multicloud, and on-premises – and when you want data masking and long audit retention without running and sizing an appliance.
- Use both when your estate spans both worlds: for example, Security Central as the customer-managed fleet appliance for your on-prem and self-managed databases (with the Database Firewall and unified policy plane), and Data Safe for the managed side where you want masking and cloud-native automation. They are designed to cover different deployment postures, so running them together to match where each database actually lives is a coherent design, not a duplication.
Compliance reports and attestations
Security Central produces the artifacts a compliance review actually consumes. It ships prebuilt reports for GDPR, PCI DSS, HIPAA, SOX, IRS 1075, and the UK DPA, and it maps Configuration360 assessment findings to CIS Benchmarks, DISA STIGs, and GDPR. It can also schedule recurring assessments and attest the results, for continuous audit readiness..
Wrapping up
If you run Audit Vault and Database Firewall today, the most important thing in this article is that Oracle has not handed you a new product to learn. Database Security Central is what AVDF evolves into: the same foundation we already operate, with a broader fleet-level view added on top, and a documented, reversible path to get there rather than a forced big-bang cutover.
What changes is the scope of what one platform can answer. Instead of per-database monitoring, you get correlated risk across users, sensitive data, configuration drift, and activity, and a policy that is written once and applied fleet-wide, and a natural-language way to ask the platform questions. The path to get there is a controlled transition with the original system available as a fallback, and there is a no-additional-cost window for eligible customers running until the end of February 2027.
This sits next to Oracle Data Safe rather than replacing it. The two products share a common set of security controls but come in two shapes: Security Central is the customer-managed appliance (with the network-level Database Firewall) which can be complemented with Datamasking and Subsetting option, and Data Safe is the managed cloud service (with data masking and long audit retention). You pick based on where your databases run and how much of the security management plane you want to own, and a large estate can reasonably run both to match each side.
