Lessons from Ascend 2026: EBS Security Has Become a Continuous Discipline

This is the third post in the Chiton Guard blog series. The first post introduced why I came out of retirement and founded Chiton Guard. The second post laid out the EBS security maturity model framework the series follows. This post covers what I heard and observed at Ascend 2026.

Ascend 2026, held in Orlando in June, is the largest Oracle E-Business Suite user conference of the year. I had a great time: catching up with current and former Oracle colleagues, talking directly with customers about what they’re actually dealing with, and getting a clear read on where the EBS community stands.

The theme from the security track was consistent: security has moved from a quarterly maintenance problem to a continuous operating discipline. Oracle is accelerating the security release cadence, attackers are moving faster, and the platform’s built-in defenses are becoming more important.

But faster patch availability does not mean patches can be deployed immediately. EBS environments are highly customized, and responsible teams still need time to understand dependencies, test changes, and move them safely into production. That creates an unavoidable window between vulnerability disclosure and patch deployment—a window attackers increasingly know how to exploit.

Closing that window is central to the work we are doing at Chiton Guard. The goal is not to replace patching, but to provide EBS-specific protection while patches are being evaluated and deployed, while also helping teams understand dependencies, measure actual exposure, and focus remediation where it matters most.

That tension—between growing urgency and limited implementation capacity—was the consistent theme I heard in the security sessions and customer conversations in Orlando.

The Number One Pain Point: Keeping Up with Patching

The patching cycle was the dominant concern I heard from EBS practitioners throughout Ascend.

Oracle’s response to the changing threat environment is now a monthly cadence. The quarterly Critical Patch Updates (CPUs) continue: January, April, July, October. Oracle has added Critical Security Patch Updates (CSPUs) filling the off-months. The first CSPU shipped May 28, 2026. The schedule going forward is the third Tuesday of each month.

This is a sensible response to a threat landscape where exploitation can begin within days of a public disclosure. But the operational reality for most EBS teams is that even quarterly patching strains their testing capacity. Many are already applying every other CPU, or every fourth. Monthly is a significant escalation.

Along with the cadence of the patches, customers should expect the number of fixes to increase substantially. The just released July 2026 E-Business Suite CPU contains 410 new security patches. In the new world of AI, that number is likely to be indicative of the workload EBS teams should now plan for going forward.

The advice I gave customers comes in two parts. First: invest in understanding your database and code interdependencies. CPU testing is slow because teams don’t know in advance which customizations and integrations a given patch is likely to touch. The teams with the most mature patch processes have done the upfront work to map those dependencies, which allows them to narrow and focus their testing. Second: get ahead of the exploit window. Even with strong testing discipline, there will be lag between patch release and deployment. The ability to block known exploits at the web tier before a patch is applied is an increasingly important compensating control. It does not replace patching, but an EBS-aware compensating control can reduce exposure during the testing and deployment window.

What Oracle Is Saying: Kevin Hudson and Lisa Parekh

Kevin Hudson, Oracle’s Vice President of Architecture and Product Management for Applications Development, gave one of the clearest articulations of the security problem I’ve heard from inside Oracle. The threat has changed fundamentally. EBS environments now face continuous, automated scanning and exploitation at scale, with AI accelerating every stage of the attacker’s work. The guidance for what to do about it has been consistent. The urgency has escalated.

His prescription was direct: keep current, and implement defense in depth. Keeping current means CPU and CSPU compliance across the EBS code, the technology stack (OHS, WebLogic, JDK, database), and any optional integrations. Defense in depth means running the Secure Configuration Console, enabling Allowed Resources and the URL Firewall, and deploying a properly configured DMZ architecture and URL Firewall when external access is required.

The Secure Configuration Console currently runs 29 checks across two severity levels and is a solid starting point for understanding where your environment stands. Chiton Guard’s free Configuration Assessment provides a complementary, automated review across the EBS database, application, and web tiers.

Lisa Parekh, now Group Vice President for E-Business Suite, also presented on the security capabilities available within the platform. Lisa recently stepped into this role when my former boss Cliff Godwin retired after many years leading EBS. I worked with Lisa throughout much of my career at Oracle and am confident she will continue to lead EBS forward. Her session reinforced the same core message: there are a lot of strong security features built into E-Business Suite. The challenge is understanding, activating, and configuring them correctly.

The OATUG Security SIG: Barone, Channell, and Behn

Michael Barone, David Channell, and Susan Behn presented a practical session through the OATUG Security SIG aimed at teams working through their hardening priorities.

The session covered the checker toolkit: ECPUC for CPU compliance, EJCPUC for Java, and ETCC for technology code level. They also covered DB-SAT, Oracle’s Database Security Assessment Tool, which provides a structured review of database security configuration. The Secure Configuration Console and Allowed Redirects featured prominently, as did a pointer to the E-Business Suite Security FAQ, which is probably the single most useful quick reference for EBS security administrators.

One angle they raised that deserves more attention: cyber insurance. Compliance with CPU patching and implementation of Oracle’s recommended security features can be a requirement to maintain coverage under some policies. If your organization carries cyber insurance, it is worth understanding what your policy actually requires and verifying that you can demonstrate compliance.

I was invited to add a few comments after both Kevin Hudson’s presentation and the Security SIG session. In each case, I emphasized two implementation issues: retaining enough evidence to understand actual behavior, and moving the Allowed Resources family of controls beyond nominal enablement into tested, environment-specific enforcement. Both of these topics will get their own posts in this series.

Conversations from the Floor

Some of the most useful conversations happened outside the formal sessions.

Database Vault: matching the tool to the use case. Database Vault is a powerful tool, and like most security features, its value comes from matching the implementation to the specific problem you are trying to solve. Limiting the data that can be accessed by connections coming in from a DMZ tier is an excellent example of what Database Vault does well: for example configuring additional sensitive realms that cannot be accessed via the DMZ. That is a meaningful reduction in attack surface for environments with internet-facing EBS deployments.

The operational consideration is patch complexity. Some patch operations have historically required elevated database access that Vault can block, creating friction in the patching workflow. The EBS System Schema Migration addresses this directly: migrating from SYS/SYSTEM to EBS_SYSTEM reduces the predefined EBS realms from five to two and substantially simplifies Database Vault integration and patch administration. Organizations evaluating Database Vault should plan the System Schema Migration first.

Controlled removal with a recovery path. A large university system raised a privacy-driven requirement without a clean out-of-the-box answer: remove individuals’ records from the live environment while preserving the ability to recover them if the removal decision were later reversed. They had been considering the Privacy Data Removal Tool (PDRT) and asked whether its application-level removal workflow could be combined with a controlled recovery mechanism. I suggested exploring PDRT for the supported removal process while preserving the pre-removal state in a separate, tightly restricted archive. Any restoration would require a carefully designed, tested, application-aware process, along with appropriate privacy and legal controls. This could allow them to reuse the PDRT infrastructure while minimizing the amount of custom removal code.

AI integration through secure views. Ask EBS is beginning to appear in customer discussions following its introduction last year, and its security model is worth understanding. It exposes EBS data to natural-language queries through controlled views designed to reuse established EBS data-security context rather than giving the AI unrestricted database access.

The Next-Generation Technology Stack

One of the more forward-looking discussions at Ascend centered on Oracle’s next-generation EBS technology stack upgrade. Oracle plans to make the new technology stack available without requiring a major EBS application upgrade. For organizations that have deferred technology stack updates because of the application-level testing burden, this changes the calculation significantly.

The security implications are substantial. The new stack brings TLS 1.3 support and better certificate management at the tooling level. Java 17 brings meaningful security improvements over the Java 7 and 8 levels EBS environments are currently running. Modern levels of OHS and WebLogic follow the same pattern.

Justin Derrick and Mike Miller presented an excellent session on certificate best practices that reinforced why the tech stack upgrade matters beyond just version currency. Certificate lifecycle management is becoming more operationally demanding: the industry is tightening expiration windows, and automated rotation is increasingly a requirement rather than a convenience. Managing that manually at scale is not realistic. The new tech stack and OCI provide certificate management that is a meaningful part of the answer.

Mike and Justin also pointed out that post-quantum cryptography is likely to become a compliance requirement. The current EBS technology stack is poorly positioned to accommodate the resulting protocol and certificate changes. They argued that moving to the next-generation stack will provide a more adaptable foundation for that eventual transition. Organizations that defer the upgrade are therefore not just carrying current security debt; they may also be making future transitions harder.

What I Took Away

The EBS community understands the problem. The concern about the threat landscape is genuine and widespread. The operational path from awareness to action is where teams need help.

The patching cycle is straining teams. The security features are there but underutilized. The logging data exists but is not being retained or analyzed. Oracle’s defense-in-depth guidance is solid. Most environments are not all the way through it.

That gap is what the rest of this blog series addresses. The next posts will work through the maturity model level by level, starting with platform hygiene and visibility, and building toward what a well-defended EBS environment looks like in practice.

Understand Your Exposure Before the Next Patch Window

Patching remains essential, but most EBS teams cannot test and deploy every security update immediately. The first step toward reducing that exposure is understanding how the environment is configured today.

Chiton Guard’s free Secure Configuration Assessment performs a read-only review across the database, application mid-tier, and external front end. It identifies configuration gaps, provides a defensible baseline, and helps establish where immediate mitigation and longer-term remediation should begin.

---

Eric Bing is the founder and principal security architect at Chiton Guard. He spent 32 years working on Oracle E-Business Suite, including 12 years leading the EBS security and privacy team.