Credential Harvesting and the Authorization Gap in Financial Services

On an unremarkable Tuesday in April 2026, thousands of RBC Direct Investing clients received an email telling them their W-8BEN tax form had expired.

The email looked right. The sender address matched an internal RBC system. The language was regulatory — “continued compliance,” “accurate tax treatment,” “uninterrupted account processing.” The link said “Click Here.”

Some clicked. They landed on a portal that looked like RBC. They entered their credentials, their personal information, their tax data. And then the attackers had everything they needed — not to hack into RBC, but to log in.

What happened next is the part nobody talks about. And it’s the part that matters most.

Executive Summary

This paper examines an active phishing campaign targeting RBC Direct Investing clients — not because the attack itself is novel, but because of what it exposes about the structural defenses of financial institutions. The campaign is a textbook credential harvesting operation: spoofed sender, urgency language, fake portal, stolen credentials. Every financial institution has defenses against this. None of those defenses address what happens after the credential is harvested.

We call this the Authorization Gap — the disconnect between authenticating an identity at the perimeter and continuously authorizing that identity’s actions across applications, infrastructure, data, and AI workloads. The data is clear:

22%

of breaches start with stolen credentials (Verizon DBIR 2025)

246 days

mean time to identify + contain credential breaches (IBM 2025)

$6.08M

avg. financial services breach cost (IBM 2025)

Authentication answers “Who is this?” Authorization answers “Should this identity be doing this, right now, in this context?” Financial institutions invest billions in the first question. The second question goes largely unanswered at runtime. This paper presents a technical framework for closing that gap.

1. Anatomy of the Attack

The RBC Direct Investing phishing campaign follows a well-established credential harvesting playbook, adapted for the financial services regulatory context. Its sophistication lies not in the technology but in the targeting.

1.1 Attack Mechanics

Delivery: Spoofed emails impersonating RBC Direct Investing’s internal systems. The From: header is forged to appear as a legitimate RBC domain, bypassing casual inspection.

Pretext: Urgent W-8BEN tax form renewal. Non-U.S. tax residents with investment accounts are required to periodically renew these forms, making the pretext immediately credible to the target population.

Social engineering: Urgency language (“continued compliance,” “uninterrupted account processing”) creates time pressure designed to override critical evaluation. No contact information or independent verification path is provided — a deliberate isolation tactic.

Capture: Victims are directed via hidden hyperlinks to a fraudulent portal mimicking RBC’s login interface. The URL is masked behind text (“Click Here”), preventing destination verification. Credentials, personal information, and tax/financial data are harvested.

1.2 Technical Indicators

Indicator

Detail

Detection Difficulty

Spoofed sender

Forged From: header mimics internal RBC domain

Medium — SPF/DKIM/DMARC can flag

Hidden URL

Hyperlink text masks actual destination

Low — standard phishing technique

No contact info

No phone number or support channel

Low — absence of verification path

Urgency framing

Compliance/regulatory language creates pressure

High — mimics real institutional comms

Tax form pretext

W-8BEN is a real regulatory requirement

High — context-appropriate for targets

1.3 Why This Attack Works

The campaign targets a specific population (non-U.S. tax residents with investment accounts) with a specific pretext (a real regulatory requirement). It exploits domain knowledge of financial services compliance to increase credibility. This is not spray-and-pray phishing. It is targeted credential harvesting designed to produce high-quality, immediately usable credentials.

2. The Authentication Ceiling

Financial institutions have invested billions in authentication infrastructure: MFA, adaptive authentication, behavioral biometrics, email security gateways. These investments are necessary. They are also insufficient. They address the wrong phase of the attack lifecycle.

2.1 The Kill Chain — and Where Defenses Stop

Figure 1: The Credential Harvesting Kill Chain — existing defenses cover Phases 1–4. Phase 5 (lateral action) has no defense.

The critical failure is at Phase 5. Once a stolen credential passes authentication — even MFA in some scenarios — the identity is trusted. Every subsequent action is authorized by default. The attacker inherits the victim’s full permission set with no runtime verification.

2.2 The Evidence

The Verizon 2025 Data Breach Investigations Report, covering over 22,000 security incidents, found that stolen credentials remained the most common initial access vector, accounting for 22% of all breaches. In basic web application attacks, the figure was 88%. IBM’s 2025 Cost of a Data Breach Report found that breaches initiated with stolen credentials had a mean time to identify and contain of approximately 246 days — eight months of undetected access.

The Verizon DBIR’s credential stuffing analysis adds another dimension: in analyzing single sign-on provider logs, researchers found that credential stuffing accounted for 19% of all authentication attempts on a median daily basis. These attacks try each stolen credential only once per account, blending into normal traffic and rarely triggering rate-limiting or lockout protections.

2.3 Why MFA Is Not Sufficient

MFA reduces the success rate of credential replay. It does not eliminate it. Multiple techniques bypass MFA in credential harvesting scenarios:

• Real-time phishing proxies (Evilginx, Modlishka): Intercept MFA tokens by proxying the legitimate login session, capturing both the credential and the session token simultaneously.
• Session hijacking: Once a session token is captured, MFA is irrelevant — the attacker operates within an already-authenticated session.
• Push fatigue and SIM swapping: Social engineering attacks against the MFA mechanism itself.
• Token theft via infostealers: The 2025 DBIR found that 30% of enterprise-licensed devices and 46% of unmanaged devices in infostealer logs contained company credentials. Among ransomware victims, 54% had prior credential exposure in infostealer logs.

The fundamental limitation is architectural: MFA is an authentication control. It verifies identity at the point of entry. It has no visibility into what happens after the door opens.

3. The Authorization Gap in Financial Services

The Authorization Gap is the structural disconnect between authenticating an identity and continuously authorizing that identity’s actions across systems, data, and workloads. In financial services, this gap is amplified by the most dramatic shift in enterprise identity management history: the explosion of non-human identities.

3.1 The Non-Human Identity Multiplier

CyberArk’s 2025 Identity Security Landscape study, conducted across 2,600 cybersecurity decision makers globally, found machine identities now outnumber human identities by more than 80 to 1 — with nearly half carrying sensitive or privileged access. Entro Labs’ H1 2025 NHI Risk Report documented a 44% year-over-year growth in non-human identities, with the ratio reaching 144:1 in some environments. In financial services, with its dense integration of trading systems, compliance automation, and AI-driven analytics, ratios of 96:1 or higher are reported.

When a human credential is compromised, the attacker gains access not only to the human’s direct permissions but to every system, API, and automated workflow that trusts that identity’s session. The blast radius extends across the full non-human identity graph connected to the compromised account.

3.2 The Four Domains of Authorization Failure

The Authorization Gap manifests across four interconnected domains. A single compromised credential cascades through all of them:

Figure 2: A single compromised credential cascades across four authorization domains, amplified by the non-human identity graph.

3.3 Why Financial Services Is Uniquely Exposed

• Regulatory complexity: DORA, SOX, GDPR, and PCI-DSS mandate access controls — but audits verify policy existence, not runtime enforcement. A credential that passes authentication satisfies the audit, even if post-authentication behavior is anomalous.
• Legacy system sprawl: Core banking, trading platforms, and wealth management applications predate modern identity architectures. Authorization is siloed per application with no unified policy layer.
• High-value data density: Concentrated PII, tax records, account balances, and transaction histories across multiple regulatory jurisdictions. IBM reports customer PII was compromised in 53% of breaches in 2025.
• AI adoption acceleration: Investment research, risk modeling, fraud detection, and customer service are deploying AI agents with service account credentials that expand the NHI surface. 68% of organizations report lacking identity security controls for AI (CyberArk 2025).
• Recovery confidence declining: Only 28% of organizations believe they could fully recover from a cyber incident in 12 hours or less, down from 43% in 2024 — reflecting the complexity of non-human identity sprawl.

4. Closing the Gap: Continuous Authorization Enforcement

Addressing the Authorization Gap requires a fundamental architectural shift: from point-in-time authentication to continuous, context-aware authorization enforcement across every identity, every action, and every domain.

4.1 Architectural Requirements

Requirement

Description

Post-Phishing Impact

Continuous verification

Every action authorized at runtime, not just at login

Stolen credential cannot operate unchecked after authentication

Context-aware policy

Decisions incorporate identity, action, resource, time, location, behavioral context

Anomalous behavior triggers enforcement immediately

Unified policy engine

Single policy layer across all four domains

No gaps for lateral movement after compromise

NHI coverage

Service accounts, API keys, and AI agents under same policy as humans

Blast radius contained across full identity graph

Policy-as-code

Authorization rules versioned, tested, deployed like software

New policies enforced in hours during active campaigns

Audit-complete logging

Every decision logged with full context

Forensic trail from first anomalous action, not detection

4.2 The AI Security Fabric Architecture

EnforceAuth implements these requirements through the AI Security Fabric — a unified authorization enforcement layer operating continuously across all four domains.

Policy Engine (OPA/Rego-based)

Authorization policies are expressed as code using Open Policy Agent and Rego. Policies are version-controlled in Git, tested in CI/CD pipelines, reviewed via pull requests, and deployed alongside application code. When a phishing campaign is detected, new behavioral policies can be authored, tested, and enforced within hours. This is the operational advantage of policy-as-code: your security posture evolves at the speed of your engineering team, not the speed of your security team’s ticket queue.

Continuous Identity Engine

Rather than trusting an identity for the duration of a session, the Continuous Identity Engine re-evaluates authorization at every decision point. Each API call, data access request, and infrastructure action is evaluated against current policy, current context, and current behavioral baselines. A stolen credential that behaves differently from the legitimate user — different device, different time zone, different access pattern, different action sequence — triggers policy enforcement immediately. The identity is not revoked at the perimeter; the specific action is blocked or stepped up at the point of execution.

Unified Decision Log

Every authorization decision — granted or denied — is logged with full context: identity, action, resource, policy version, evaluation result, and environmental metadata. This creates a complete forensic record from the first moment a compromised credential deviates from expected behavior — not from the moment a SOC analyst notices an anomaly days or weeks later.

4.3 Applied to the Phishing Scenario

Figure 3: Without continuous authorization, stolen credentials operate freely. With the AI Security Fabric, every action is independently authorized.

Key Insight

The goal is not to prevent the phishing email from arriving. The goal is to ensure that even when a credential is successfully harvested, the attacker cannot operate freely inside the system. Continuous authorization makes stolen credentials operationally useless.

5. Regulatory Alignment

Financial regulators are moving beyond authentication mandates to require evidence of continuous access governance. Continuous authorization enforcement directly addresses requirements across multiple frameworks:

Framework

Relevant Requirement

How Continuous Authorization Satisfies It

DORA (EU)

Real-time monitoring of ICT access and operations

Every authorization decision evaluated and logged in real time

SOX

Section 404: internal controls over financial reporting access

Policy-as-code with complete audit trail for every access decision

GDPR

Article 25: data protection by design; Article 32: access controls

Context-aware data access policies enforced continuously for human and NHI

PCI-DSS

Req 7: need-to-know; Req 10: audit trails

Unified policy engine enforces least-privilege across CHD environments

EU AI Act

High-risk AI: oversight, transparency, logging

AI workload authorization independently evaluated; every decision logged

NIST AI RMF

GOVERN and MANAGE: AI risk governance and monitoring

AI Security Fabric provides governance layer for AI agent authorization

Critically, continuous authorization shifts compliance from periodic attestation to continuous evidence. Rather than demonstrating policy existence during quarterly audits, financial institutions can demonstrate real-time policy enforcement — a materially stronger compliance posture that frameworks like DORA are beginning to require explicitly.

6. Implementation Architecture

6.1 Integration Model

The EnforceAuth AI Security Fabric integrates with existing security infrastructure rather than replacing it. The platform consumes identity signals from deployed IdPs (Okta, Microsoft Entra, Ping Identity), SIEM event streams, and behavioral analytics platforms. Authorization policies reference these signals as context inputs, enabling sophisticated enforcement without requiring replacement of authentication systems.

Decision Point Architecture

EnforceAuth deploys authorization decision points at each domain boundary — application API gateways, infrastructure control planes, data access layers, and AI agent orchestrators. Each decision point calls the centralized policy engine with the current identity context, requested action, and environmental metadata. The policy engine evaluates against the current policy set and behavioral baselines, returning an allow, deny, or step-up decision in sub-millisecond latency.

IdP Integration

Rather than replacing existing identity providers, EnforceAuth sits downstream of authentication. It receives identity assertions from your IdP and enriches them with continuous contextual signals: device posture, network location, time-of-day patterns, action history, and behavioral baselines. This means deployment does not require re-architecting your authentication infrastructure.

6.2 Phased Deployment

• Phase 1 (Weeks 1–4): Client-facing applications. Establish behavioral baselines for human user populations. Integrate with existing IdP. Deploy decision points at application API gateways. Begin logging all authorization decisions.
• Phase 2 (Weeks 5–8): Infrastructure authorization. Cloud IAM, Kubernetes RBAC, and CI/CD pipeline access brought under unified policy control. Cross-reference application-layer identity with infrastructure-layer actions.
• Phase 3 (Weeks 9–12): Data access authorization. Row-level, column-level, and dataset-level policies enforced continuously based on identity, context, and data classification. Integration with data catalogs and DLP systems.
• Phase 4 (Weeks 13+): AI workload authorization. Agent identity management, action-level enforcement, and AI-specific compliance frameworks for DORA and EU AI Act. Each AI agent registered as an independent identity with its own policy scope.

6.3 Performance

Financial services environments require sub-millisecond authorization latency for real-time transaction processing. The EnforceAuth policy engine is optimized for high-throughput evaluation — processing millions of authorization decisions per day with p99 latency targets appropriate for trading, payment, and wealth management workloads. The free tier supports 1 million authorization decisions per month, enabling teams to validate performance in their environment before enterprise deployment.

7. The Calculus of Inaction

Financial services breach costs now average $6.08 million per incident. Credential-based breaches take 246 days to identify and contain. Non-human identities are growing at 44% year over year with 97% carrying excessive privileges. Sixty-eight percent of organizations lack identity security controls for AI. Recovery confidence is declining.

The question is not whether your clients will be phished. It is what happens — at every subsequent action, across every domain, through every non-human identity in the blast radius — after a credential is compromised.

The answer, today, for most financial institutions: nothing. No continuous verification. No behavioral context. No action-level enforcement. No unified policy across domains. The attacker logs in and operates freely for an average of eight months.

Closing the Authorization Gap is not a feature request. It is an architectural imperative.

Polite AI ≠ Secure AI. Point-in-time authentication ≠ continuous authorization.

About EnforceAuth

EnforceAuth is the AI Security Fabric — a unified platform for continuous authorization enforcement across applications, infrastructure, data, and AI workloads. Founded by Mark Rogge, former CRO at Styra (acqui-hired by Apple), GitLab, and Weights & Biases, EnforceAuth addresses the Authorization Gap with policy-as-code architecture purpose-built for the AI era.

Request a technical assessment: enforceauth.com

Sources

Verizon, 2025 Data Breach Investigations Report (22,000+ security incidents analyzed)

IBM, 2025 Cost of a Data Breach Report

CyberArk, 2025 Identity Security Landscape (2,600 cybersecurity decision makers, 20 countries)

Entro Labs, NHI & Secrets Risk Report H1 2025

ManageEngine, 2026 Identity Security Outlook

© 2026 EnforceAuth, Inc. All rights reserved.