An examiner or audit finding
The most common trigger, and the one with a date attached. Start with the finding, map it to the control that failed, and fix the control rather than the finding.
Identity Security for Financial Services
Banks, credit unions and financial firms are the most-examined organizations there are, and privileged access to core banking, payments and trading systems is the prize. The hard part is rarely the policy. It is that the systems holding the money are often decades old, and the access controls examiners want were designed for systems built this century.
SOX 404PCI-DSSGLBANYDFS 23 NYCRR 500FFIEC
30 June 2025 · PIXOne login, six institutions
One vendor loginC&M Software · sold for roughly $2,700
The loginsix institutions
123456
Watchingalerts
nobody, at the hour it was used
InstitutionsSix
Software vulnerabilityNone
Lost, per public reporting~$100M
Not a clever exploit. A credential that was valid, privileged and unwatched.
What happened
One bought login, one night, six institutions
Earlier in 2025, an IT employee at C&M Software — a firm that connects Brazilian financial institutions to the central bank's PIX payment system — sold his login credentials for roughly $2,700. On 30 June 2025, attackers used them to run fraudulent transfers across six financial institutions. Public reporting puts the loss at around $100 million, with some estimates higher. There was no software vulnerability. There was a vendor credential with more reach than anyone had checked, and nobody watching it at the hour it was used.
That is the shape of most financial-sector incidents: not a clever exploit, but a credential that was valid, privileged and unwatched. It is also why the four things that matter in this sector are the four things below.
The four constraints
Why privileged access is harder in banking than anywhere else
- Legacy core systems. Core banking, mainframe and RACF environments were not designed to be brokered, vaulted or session-recorded. Modern tooling does not connect to them cleanly, and this is where rollouts stop — not at the design stage, but at the third onboarding wave, when the platform team hits the AS/400 that runs the general ledger.
- Third-party and offshore access. The access that causes the incident is usually not an employee's. It belongs to a vendor, a contractor or an offshore team, it was granted for a project, and it was never cleanly removed. The Brazil case is the clearest example, and it is not unusual.
- M&A sprawl. Every acquisition brings another directory, another set of orphaned accounts, and another core system nobody documented. Access reviews that were manageable across one estate become impossible across three.
- Always-on privilege. CyberArk's January 2026 research found that 91% of organizations have at least half of their privileged access always-on, and only 1% have fully implemented just-in-time access. Banks are not the exception — the accounts that can move money are the ones most likely to be standing.
The Privileged Access Blind SpotApplied IAM
- Incident 01the gap behind it
- Incident 02the gap behind it
- Incident 03the gap behind it
Free brief. No cost, no obligation.
The framework
What SOX 404 actually requires of access control
SOX Section 404 requires proof that only the right people can reach financial reporting systems, and that the controls around them operate. This is what releases budget, and saying so plainly is more useful than listing five frameworks. The CEO and CFO sign personally and carry personal liability for it. The audit committee oversees. The CISO runs the program day to day. An external auditor verifies annually.
Three things follow for identity specifically. Separation of duties has to be provable, not asserted — the person who can create a vendor cannot be the person who can pay one. Access reviews have to complete, with evidence that a manager actually looked rather than clicked approve. And privileged sessions on financial reporting systems have to be recorded, because "who changed this and when" is the first question an examiner asks.
Alongside SOX: PCI-DSS where cards are handled, GLBA and its Safeguards Rule, NYDFS 23 NYCRR 500 for institutions doing business in New York, and FFIEC examiner expectations. Institutions with European or cross-border exposure add DORA and SWIFT CSP. The overlap is large, and most of the identity work is shared. Where an examiner finding is the trigger, that starts with a compliance readiness assessment; where the underlying problem is a governance one, it becomes an IGA implementation.
SOX Section 404
Only the right people can reach financial reporting systems, and the controls around them operate.
- SignCEO and CFOPersonally, with personal liability
- OverseesAudit committee
- RunsCISOThe program, day to day
- VerifiesExternal auditorAnnually
Three things follow for identity
Separation of dutiesProvable, not asserted
Create a vendorPay one
Access reviewsCompleted, with evidence
A manager actually lookedClicked approve
Privileged sessionsRecorded on financial reporting systems
“Who changed this and when”
The estate
The systems we secure
Core banking platforms including FIS, Fiserv, Jack Henry and Temenos. Payment and cardholder systems. Trading and capital markets platforms. Financial reporting and ERP on Oracle and SAP. Mainframe and legacy environments including RACF. Directories and cloud. Platform names are trademarks of their respective owners.
Triggers
Where a program usually starts
A failed access review
Reviews that come back empty, late or rubber-stamped are a governance problem, and the answer is usually automation rather than more reminders. See IGA implementation.
An incident involving third-party access
Vendor credentials brought under control first, through brokered sessions rather than VPN and shared passwords. See PAM implementation and CyberArk implementation.
Where the finding involves cardholder systems, PCI penetration testing is usually required alongside the access work. And because the initial compromise is so often a phishing email to someone in finance, email security sits closer to this sector than most.
01Turn audit season into a non-eventAutomated access reviews and certifications, enforced segregation of duties, and audit evidence you can produce on demand
then
02Make privileged access provableCore banking, payment and trading credentials vaulted, privileged sessions recorded, standing admin replaced with just-in-time access
then
03Keep controls tight between examsWe operate your identity program day to day so it stays exam-ready in the months between audits
Controls drift the moment a project ends — new accounts, new vendors, missed reviews.
Proof
Finance in practice
Banking group. Privileged access was being approved against change requests that had already expired: an audit finding waiting to happen and a control that looked fine on paper. Our engineers built a custom integration validating every request against its change ticket automatically. 20,000 requests a day are now checked, and approval time fell from 15–20 minutes to under five. How the change-validation integration works
FAQs
What finance teams ask us first
By making the controls produce the evidence themselves. Session recordings, completed access reviews and separation-of-duties reports come out of the platform on demand, rather than being reconstructed from spreadsheets the week before the exam. Where a framework deadline is the driver, a compliance readiness assessment maps every gap to the clause it fails.
Yes, and it is usually the reason we are called. Privileged sessions to legacy systems are brokered and recorded even where the system itself cannot integrate, and credentials are vaulted and rotated through connectors built for the platform in question. This is the part most rollouts stall on, and it is the part we plan first.
Brokered sessions with recording, credentials the vendor never sees, expiry set at grant rather than discovered at audit, and offboarding that actually runs. The Brazil case happened because a vendor credential had standing reach and nobody was watching. Neither of those has to be true.
Who has privileged access to financial reporting systems, who approved it, when it was last reviewed, and what they did with it. Four questions, and every one of them is answerable from a properly deployed platform in minutes.
It can, but it gets more expensive. Every acquisition adds a directory and a set of orphaned accounts. Bringing privileged access under control before the integration means the new estate is onboarded into a working model rather than adding to an ungoverned one.
Related reading
Go deeper
Blog
CyberArk Competitors: An Implementer's Honest Comparison
Most CyberArk PAM comparisons are written by vendors selling against it. Here is what actually differs, from a team that deploys these platforms.
Aug 25, 2026
Blog
What Is PAM (Privileged Access Management)? A Plain-English Guide
PAM secures the accounts with the most system power. Here's what privileged access management does and why attackers go after these credentials first.
Jul 28, 2026
Blog
Identity Security Posture Management: What ISPM Is and Whether You Need It
Owning PAM and IGA is not the same as knowing your identity risk. What identity security posture management actually measures.
Jul 27, 2026See where your privileged access really stands
A free audit is a 30-minute review of your privileged accounts by a certified engineer, with the findings in writing. The Finance blind spot brief covers three recent financial-sector breaches and the access gap behind each.