The Oracle EPM Cloud security model is the layered access control system that governs every aspect of user access to EPM applications — authentication (who can log in), application access (which applications a user can open), feature access (which actions a user can perform within an application), and data access (which dimension members and data intersections a user can read or write). Each layer is implemented through a different mechanism, and a complete security design must address all four layers. A security model that is rigorous at the application level but permissive at the data level leaves financial data exposed in ways that the application-level restriction gives no indication of.
Security Layer Architecture
| Layer | Mechanism | Where Configured |
|---|---|---|
| Authentication | Oracle IDCS — SSO, MFA, password policy | IDCS console; integrated with enterprise IdP via SAML |
| Application access | EPM Cloud predefined roles — Service Administrator, Power User, User, Viewer | EPM Cloud User Management; provisioned through IDCS groups |
| Feature access | Planning application roles assigned per application — what forms, rules, task lists a user can access | Planning application security administration |
| Data access | Security filters on Essbase dimensions — restricting which members a user can read or write | Planning application security filters and data access grants |
The data access layer is the most granular and most critical for finance applications. Security filters define which members in the Entity dimension a subsidiary finance team member can access, which Scenario members a budget preparer can write versus read, and which Account members a FP&A analyst can see but not write. A user who has a Planning User role can theoretically access all data in the application; security filters restrict that access to the appropriate subset. Without security filters, a Planning User role grants access to all data — which is rarely the intended configuration in an enterprise finance environment.
Design Considerations
Security filter design at scale requires a decision about the filter architecture: individual filters per user (granular but high maintenance overhead), group-based filters (filters assigned to groups, users assigned to groups — more maintainable), or dynamic security (filters that use the logged-in user’s identity to resolve their data access at runtime from a security mapping table, rather than assigning static filters). Dynamic security is the most maintainable approach for environments with frequent user access changes — adding a new entity to a user’s access requires a data change in the security mapping table, not a filter configuration change in the Planning application.
What Goes Wrong in Practice
The specific EPM Cloud security failure that most frequently creates audit and compliance exposure is assigning the Service Administrator predefined role to functional users for troubleshooting purposes and failing to remove the elevated access after the troubleshooting is complete. The Service Administrator role in Oracle EPM Cloud bypasses all application-level and data-level security restrictions — a Service Administrator can read and write all data in all applications in the environment. When troubleshooting access is granted as Service Administrator and the access is not revoked on a defined schedule, the effective security model of the production environment diverges from the designed model — and the divergence is invisible to application-level security reports, because Service Administrator access appears as a role assignment rather than as a security filter exception.
How Loop Wise Solutions Handles This
We implement a security model governance process for every EPM production environment — quarterly access reviews using the EPM Cloud user and role reports, a defined maximum duration for any temporary elevated access grants, and a change log for all security modifications. Service Administrator role assignments to non-system-administrator users are flagged as exceptions in the access review, with mandatory documentation of the business justification and a defined expiry date for the elevated access.
Answers before you ask.
Authentication through the Oracle identity service, predefined application roles for feature access, access permissions on artefacts and dimension members, and Essbase security filters for data-level control. These layers work together: identity proves who you are, roles grant features, and member-level security governs which data you can see and write. All must be designed as a whole.
Because a gap in any one undermines the others. A user correctly authenticated with the right application role can still see data they should not if member-level security is loose, and vice versa. Designing authentication, roles, artefact access, and data filters in isolation produces either over-exposure or blocked users — coherent design across all layers is essential.
A role grants access to features and functions — who can administer, who can only enter data. A data-level security filter (via Essbase) governs which dimension members a user can read or write. One controls what you can do in the application; the other controls which slice of data you can touch. Both are needed for correct access.
Authentication, handled by the Oracle identity service and identity domain, establishes who the user is before any application access is evaluated. It is the outermost layer — feature roles and data filters only apply once identity is proven. Managing the identity domain, users, and their assignment is therefore the foundation the rest of the security model rests on.