Back to Case Studies

How a Global Fintech Closed the Gap on Standing Privilege Across Every Environment

Discover how Britive's native multi-cloud platform removes the complexity, cost, and risk of building an identity security tool that scales with your needs.

EXPLOREEXPLORE

0.25FTE

To run privileged access globally

35,500+Privileged profiles

Zero standing access

65%+Lower TCO

Versus vault-based PAM

The ProblemThe Problem

The SolutionThe Solution

OutcomesOutcomes

Access Challenges in Financial Services

The company processes billions of transactions for financial institutions worldwide, so its engineering investment should belong to the platforms that move money. Leadership set a clear mandate: eliminate standing privileged access across the entire estate, but two systems stood in the way. 

In the cloud, a homegrown tool that couldn’t scale with the business. In 2017, development teams spun up more than 100 unmanaged AWS accounts with no link to the company's identity provider. At that time, commercial multi-cloud tools didn’t exist at enterprise scale, so a small internal team built a serverless, AWS-only access tool. It worked until the company expanded into Azure, GCP, and Oracle Cloud. Extending it would have taken multiple cycles from FTE, and the knowledge of how it worked and the burden of maintenance would live in the engineers who built it. 

On-premises, a vault that managed standing credentials instead of removing them. The server and database tier held the most sensitive financial data, and non-human identities there outnumbered people: database administrator credentials and service accounts across Active Directory, Windows, Unix, and Red Hat IDM, all on static credentials with no expiry. Facing a hard audit deadline to eliminate standing privilege, the incumbent PAM couldn’t secure Oracle or MSSQL at scale, and its proxy-dependent architecture required continuous deployment of vault servers, endpoint agents, and connectors. 

No path to agentic AI from either one. Autonomous workloads need identities that request access, act, and finish tasks across cloud and on-premises boundaries at machine speed. A proxy-dependent PAM can't match millisecond-fast agent actions, and a rotation schedule can’t accommodate sub-agents spawned mid-task. Adopting AI under their old access model would have meant looking for a third access architecture on top of the existing silos. 

See how runtime authorization works

Britive's Solution

The company replaced both systems with Britive. Authorization decides and access enforcement acts at the moment of need. Privilege does not exist before work starts, and it does not survive after work ends.

One access model across cloud, SaaS, and on-premises. —  Developers and automated workloads reach AWS, Azure, GCP, Oracle Cloud, Snowflake, Splunk, and Wiz through the same policies, with checkout running natively through APIs, the command line, and existing DevOps workflows. On-premises, a script-driven broker on domain-joined hosts governs access across a management Active Directory domain, production domains, and mixed local and AD accounts on Windows and Unix.

Change-record validation at the moment of checkout. — Britive integrates with ServiceNow so that privileged access is granted only when a matching change request or incident exists, is approved, falls inside its implementation window, and matches the affected configuration items. Compliance evidence is produced by the architecture, not reconstructed before an audit.

Standing database credentials removed. — Static DBA credentials for Oracle and MSSQL are gone. Administrative database sessions now run through the same runtime model as cloud infrastructure.

Detection to remediation without standing access. — Wiz flags a risk, Torq orchestrates the response, and Britive grants only the scoped, time-limited access needed to remediate it, whether the target is a Windows server, a Linux host, a Kubernetes node, or a database. No responder holds access before or after the incident. The same engine governs agentic AI workloads on the same basis as non-human and human identities, with no separate policy engine.

Our cloud security, identity, and cloud platform engineering teams are now aligned, thanks to Britive. This alignment allows us to scale securely and focus on innovation, knowing that privileged identities are tightly controlled across our multi-cloud landscape.

[ Chris Rasco ]

Fiserv VP & Chief Cloud Architect

What Changed

Cloud Access Model: One runtime access model across AWS, Azure, GCP, Oracle Cloud, and SaaS

Platform Sustainability: Platform is easier to sustain as a vendor-supported, documented, and continuously updated product.

On-Premises Coverage: Ephemeral access to AD, Windows, Unix, Red Hat IDM, Oracle, and MSSQL

Privilege Posture: Zero standing access by default; privileges built per task and removed after

Agentic AI Readiness: One architecture for AI agents, non-human identities, and people

0.25 FTE to operate globally. Vault-based PAM typically needs a dedicated team to maintain proxies, vaults, and agents. The company runs its entire global Britive footprint on a quarter of one engineer's time.

35,500+ privileged profiles with zero standing access. Every administrative profile exists dynamically, scoped to the active task, with standing privilege on a managed path to zero across cloud, SaaS, and on-premises. 

Owner-departure risk eliminated. Security logic that once lived in the heads of the engineers who built the homegrown tool is now standardized, documented, and vendor-supported. 

Engineering capacity returned to the core platform. Multiple FTEs of development time once spent patching internal identity tooling now go to the payment processing systems the business runs on. 

Evidence by architecture. Because access is built and dissolved around each task, the audit trail shows which identity reached which database or cloud instance, under which approved change record, for how long, and with what permissions. The reactive evidence-reconstruction step before an audit is gone.