Enterprise resource planning systems rarely remain self-contained. Companies add planning tools, procurement platforms, integration services and other cloud applications as their needs change.
Each addition can also introduce a separate authentication process and another system that could fail.
A 2026 analysis of enterprise applications found that 57% bypassed centralized identity providers. The same report found that 40% of accounts remained active after the associated users had left.
Those gaps can become difficult to manage in a large SAP environment, especially when cloud applications are added individually over several years.
Vamshi Krishna Jeksani, a senior cloud solutions architect with more than 20 years of experience working with SAP environments, says identity and availability should be addressed as connected parts of a modernization project.
A user who cannot sign in and an application that cannot reach its database create the same result for the business: The system is unavailable when someone needs it.
Every application creates another access point
Cloud applications are often selected and configured one product at a time. A planning platform may maintain one user directory, while procurement and integration tools maintain others.
The result can be several versions of the same employee spread across systems, each with separate credentials, permissions and offboarding procedures.
That fragmentation creates inconvenience for users and makes it harder for security teams to determine who has access to what.
“Access friction does not stay a user problem for long,” Jeksani said. “If somebody needs three separate passwords to finish a single task, they will find a way around the controls, and the workaround becomes your actual security posture.”
Separate passwords do not necessarily mean users will create separate credentials. Verizon researchers examining infostealer records found that, in the median case, only 49% of a user’s passwords were distinct. Reusing credentials can allow a password stolen from one service to be tested against others.
Centralized identity management reduces the number of credentials employees must manage. It can also give administrators one place to grant, review and revoke access.
Single sign-on requires more than a login screen
Jeksani described an enterprise SAP project that connected planning, integration and procurement applications to a centralized corporate directory using Security Assertion Markup Language, commonly known as SAML.
SAML allows an identity provider to confirm a user’s identity to connected applications. Employees can sign in through the company’s central system rather than maintaining a separate password for every product.
The visible login process is only one part of that integration. Each application must trust the identity provider, accept a consistent user identifier and securely exchange authentication information.
Certificates used to establish those relationships also expire and must be renewed. A single sign-on deployment may work properly at launch but fail later if responsibility for certificate renewal is unclear.
“A federation is a set of promises between systems, and certificates are how those promises expire,” Jeksani said. “Most SSO implementations do not fail at go-live. They fail later, when something rotates and nobody owns the renewal.”
Companies need to document who owns each certificate, when it expires and how the updated certificate will be tested across connected applications.
Centralizing authentication also improves the audit trail. Instead of reviewing unrelated local accounts, security teams can connect authentication activity to a known corporate identity and remove access from one location when an employee leaves.
Modernization is not limited to broken systems
Identity was only one part of the project Jeksani described. The SAP environment also relied on a legacy database-mirroring configuration.
Database mirroring maintains a secondary copy that can take over if the primary database fails. However, older designs may provide only one failover partner and make it difficult to move several related databases together.
That creates a problem for an ERP application that depends on multiple databases. If only part of the application’s data moves successfully during a failure, the overall system may still be unusable.
The project replaced mirroring with a clustered availability design that supported multiple replicas and automatic failover. Related databases could move together, while read-only replicas could handle some reporting activity without competing with transactions on the primary system.
“You do not always modernize because something failed,” Jeksani said. “Sometimes you modernize because the old design has stopped letting you improve.”
Failover plans must be tested
A high-availability configuration is not proven simply because it has been installed.
Cockroach Labs reported that fewer than one-third of organizations regularly test failover, based on a survey of 1,000 senior technology executives.
Testing can reveal problems that diagrams and configuration reviews miss. Timeout settings may be too short for a real workload, applications may not reconnect properly and hidden dependencies may remain tied to the failed system.
According to Jeksani, failover exercises conducted during the SAP rebuild exposed configuration values that needed adjustment. The tests also identified application connection behavior that had not previously been exercised against a live failover.
The team adjusted the settings and repeated the recovery process before moving the environment into regular use.
“The first exercise always finds something, and that is the reason to run it,” Jeksani said. “You want the configuration to be wrong in front of you, with the whole team watching and nothing depending on the answer.”
Testing during a planned rebuild gives teams more room to correct problems than testing after a system has entered production. It also creates a documented recovery process that can be repeated during an actual incident.
Access and availability need continuing ownership
Single sign-on and database availability are often assigned to different technical teams. They may also have separate budgets and maintenance schedules.
From a user’s perspective, however, both determine whether a business application works.
Identity integrations require certificate renewals, permission reviews and testing after upgrades. Availability systems require failover exercises, dependency reviews and updates as workloads change.
Neither should be treated as a configuration that can be completed once and forgotten.
“The two questions worth asking about anything you attach to a landscape are who can get into it and what happens when it stops,” Jeksani said. “Most organizations answer the first at purchase and the second during an incident. I would rather answer both while neither one is urgent.”
©2026 Cox Media Group
