Enterprise database security has been getting harder to manage for years. The threat surface keeps expanding, compliance requirements keep tightening, and the administrative overhead of keeping up with both has become genuinely painful for most DBA teams. Oracle Database 23c doesn’t try to solve every problem at once — but it does address several areas where the previous architecture was showing its age.
I’ve spent time digging into the security enhancements in this release, and a few of them stand out as meaningful improvements rather than checkbox features. Here’s an honest look at what changed and why it matters.
The Threat Picture Oracle Is Responding To
Before getting into features, it’s worth framing the problem. Modern database security teams aren’t just defending against external attackers anymore. The threats are coming from multiple directions at once:
External attacks — phishing, SQL injection, credential theft, denial-of-service — are the obvious ones. But the internal threat category is often underestimated. Privileged user abuse, misconfigurations, accidental data destruction, and insider sabotage are all real risks that show up in breach reports with uncomfortable frequency.
Then there’s the compliance dimension. Data residency requirements, audit obligations, and governance mandates don’t go away when you’re under operational pressure. They tend to get more demanding.
Oracle’s approach here is defense in depth — securing every layer of the environment rather than treating the database as an isolated island. That means the network, OS, application, database, backup systems, and identity management all need to work together. 23c moves that model forward in several concrete ways.
Hybrid Read-Only Mode for Pluggable Databases
This one surprised me as a more nuanced approach than the traditional read-only database model.
The old problem: if you put a database in read-only mode for a reporting or compliance use case, certain legitimate temporary operations couldn’t happen — and that caused real friction. So teams would often leave databases in read-write mode “just in case,” which defeated the security purpose entirely.
The Hybrid Read-Only PDB changes the calculus. Core application data stays protected and can’t be modified, but local temporary operations can still proceed. The practical result is that you can create genuinely secure reporting environments, compliance archives, and analytics databases without breaking the things that actually need to run against them.
From a security standpoint, it also meaningfully reduces SQL injection risk. An attacker who finds an injection vector can’t use it to modify data if the session can’t write. That’s a real containment improvement, not a theoretical one.
Read-Only Users and Sessions
This is a least-privilege feature that’s long overdue at this level of granularity.
The concept is straightforward: you can now define users or individual sessions as read-only, meaning even if their credentials are stolen or a session is hijacked through an injection attack, the attacker’s ability to do damage is severely limited. They can read data, but they can’t alter it.
For organizations dealing with compromised credential scenarios — which is most organizations, whether they know it or not — this is a meaningful reduction in blast radius. It won’t prevent every attack, but it changes the calculus for attackers who are looking for writable access. A read-only foothold is significantly less valuable than a read-write one.
The New Developer Role
This one comes from a real frustration that security teams and development teams have been dealing with for years.
Developers need broad access during active development. Giving them that access properly in production environments, however, usually means granting privileges that create unnecessary risk, or going through a bureaucratic process every time someone needs to test something. Most teams end up with one of two bad outcomes: over-privileged developers, or a shadow IT situation where devs are working around controls to get things done.
The dedicated Developer Role in 23c is an attempt to solve this at the database level. It provides a structured, pre-configured set of privileges appropriate for development work, without requiring admins to manually manage individual privilege grants for every developer who onboards. It also reduces privilege sprawl — the accumulation of access rights that never get cleaned up because nobody wants to break something that might be depending on them.
It won’t work perfectly for every organization’s security model, but it’s the right direction.
Simplified Schema-Level Privileges
Managing privileges at a fine-grained level in large Oracle environments is tedious and error-prone. The complexity compounds over time as roles multiply, exceptions get added, and the original intent of the access control design gets obscured.
23c simplifies schema-level privilege administration, making it easier to enforce role-based access control without requiring admins to navigate a maze of individual grants. The goal is least-privilege enforcement that doesn’t require heroic effort to maintain. Security controls that are painful to administer tend to drift or get bypassed — simplification isn’t just a usability improvement, it’s a security improvement.
What Changed With Unified Auditing
Auditing is one of those areas where the gap between what organizations need and what they actually have tends to be significant.
The problems with traditional auditing are well-known: high overhead, massive audit volume that’s expensive to store and difficult to analyze, and limited precision that generates more noise than signal. Oracle’s Unified Audit framework already made meaningful progress on this, but 23c goes further in two specific ways.
Table and column-level audit policies let you target exactly what matters — specific tables, specific columns, specific sensitive attributes — rather than auditing at a broader level and drowning in data. Lower noise, better focus on sensitive data, reduced storage overhead, and faster detection of anomalies when something actually happens.
Database Vault integration for audit protection addresses a subtler but important problem: what happens if an attacker compromises audit administration? If they can modify or delete audit records, they can erase evidence of what they did. Database Vault in 23c restricts who can manage audit configurations and tightens separation of duties around audit infrastructure. The practical result is that audit trails remain trustworthy and forensically sound even if portions of the environment are compromised.
Azure Active Directory Integration
This is the feature that will matter most to organizations already running hybrid cloud environments with a Microsoft identity stack.
Connecting Oracle database authentication directly to Azure Active Directory means centralized user management, enterprise-grade identity federation, and single sign-on support — without maintaining a separate identity silo inside the database. User lifecycle management gets simpler. Password sprawl decreases. Compliance reporting becomes more coherent because identity is managed in one place.
For any organization that’s been running Oracle alongside Microsoft infrastructure and managing the identity seams manually, this removes a real operational burden. It’s also a security improvement: centralized identity management with strong MFA at the AAD layer is more defensible than managing separate database credentials that may or may not meet enterprise password policy.
Putting It Together
What strikes me about the 23c security changes is that they’re not trying to be flashy. There’s no single dramatic feature here — instead, it’s a collection of practical improvements that address real operational pain points: reducing attack surfaces through better access controls, improving audit precision, protecting the audit infrastructure itself, and modernizing identity integration.
That’s usually how meaningful security progress actually happens. Not through a single silver bullet, but through a series of targeted improvements that close real gaps.
For teams running regulated workloads where least privilege, audit integrity, and compliance evidence matter, several of these features will translate directly into audit findings resolved and risk assessments improved. For development teams, the developer role and simplified privilege model should reduce friction without requiring a renegotiation of security controls.
Worth testing. Worth understanding. And for most enterprise Oracle deployments, worth the upgrade conversation.
