TL;DR
- ✓Orphaned accounts from terminated employees remain active longer than most teams realise
- ✓EBS user access review should cross-reference HR data against active application users
- ✓Excessive role assignments often accumulate through project-based access that never gets removed
- ✓E-business suite account recertification should run on a defined schedule, not just at audit time
- ✓Remediation steps need to be documented to satisfy SOX, ISO, and internal audit requirements
What an Oracle EBS User Account Audit Uncovers
At its core, an Oracle EBS user account audit is a comparison exercise: who actually has access versus who should. Simple in theory. In practice, most EBS environments accumulate years of access drift — terminated employees, contractors who finished their engagement six months ago, staff who moved departments but kept every role they had ever been assigned.
Orphaned accounts are the immediate problem. They don't just sit there harmlessly. They're exploitable, and they're exactly what external auditors flag. We see this constantly during technical audits — an account still active two years after someone left the business, sitting on a set of transaction roles nobody remembered to remove.
An effective EBS user access review works like this:
- ✓Pull the full active user list from Oracle EBS
- ✓Cross-reference it against current HR records and vendor rosters
- ✓Flag any account with no matching active record
- ✓Disable and log immediately — the documentation matters as much as the action
Beyond orphaned accounts, look hard at role accumulation. This usually appears when someone was granted elevated access for a system rollout or project, the project ended, and nobody walked it back. For a structured approach to fixing what the audit uncovers, see oracle ebs access control remediation.
Scoping the Oracle EBS User Account Audit
Before you can clean up user accounts in Oracle EBS, you need a clear picture of what you're actually auditing. Start by identifying every EBS environment in scope: production, UAT, training, and any legacy instances still running. Most organisations focus only on production and overlook test environments where accounts are created freely and never removed — a genuine security exposure when they share LDAP directories or SSO configurations with production.
Defining Your EBS Audit Scope
- 1List all Oracle EBS instances (production, UAT, training, legacy) and confirm which share authentication infrastructure
- 2Pull a complete account inventory from FND_USER, including last logon date, account status, and assigned responsibilities
- 3Map each account type: named user, service account, batch processing ID, and shared or generic login
- 4Identify the business units, modules, and data classifications each account can access
- 5Confirm which HR and directory systems feed account provisioning
- 6Document the legal entities and regulatory frameworks that apply to each account category
Identifying Dormant Accounts and Excessive Entitlements
Any active EBS user record with no login activity past a defined threshold — typically 60 or 90 days — is a dormant account. To find them, query FND_LOGINS and FND_USER directly. Filter for active accounts where LAST_LOGON_DATE falls outside your threshold — and also flag accounts where it is null entirely (provisioned but never used).
EBS orphaned accounts are different — they are still active in EBS after the employee has been terminated or transferred in HR. A cross-reference between PER_ALL_PEOPLE_F and FND_USER surfaces these mismatches quickly.
Excessive access is the quieter problem. Responsibilities accumulate when a user moves from AP to GL, picks up new responsibilities, and nobody removes the old ones. Run each active user's responsibility set against your SoD conflict matrix to catch these combinations.
Complete Your Oracle EBS User Account Audit with APPSolve
We run structured EBS account audits — from scoping through to remediation — and produce the documented evidence your auditors require.