TL;DR: A phishing campaign targeting RBC Direct Investing clients used a fake W-8BEN renewal flow to harvest credentials and tax data, then relied on the fact that authentication still leaves post-login authority largely unchecked, according to EnforceAuth. The hard problem is not entry, but continuous authorisation after the login event has already succeeded.
At a glance
What this is: This analysis says the RBC Direct Investing phishing campaign exposed a financial services authorization gap: authentication stopped the login question, but not the question of what a compromised identity could do next.
Why it matters: It matters because IAM, PAM, and NHI programmes often stop at entry control, while post-login authorisation determines whether stolen credentials can move across applications, data, and automated workflows.
By the numbers:
- 22% of breaches start with stolen credentials, according to Verizon DBIR 2025 research cited by EnforceAuth.
- 246 days is the mean time to identify and contain credential breaches, according to IBM 2025 research cited by EnforceAuth.
- The ratio of machine identities to human identities reached 144:1 in some environments, according to Entro Labs H1 2025 NHI Risk Report cited by EnforceAuth.
- 68% of organizations lack identity security controls for AI, according to CyberArk 2025 research cited by EnforceAuth.
Context
A phishing email that looks like a legitimate compliance notice can still succeed even when sender reputation and login controls are in place. The deeper problem is what happens after an identity is authenticated and whether the environment keeps authorising every action that follows.
In this article, the author uses the RBC Direct Investing campaign to argue that financial services security is still too anchored in entry control. That makes post-login authorization, not just authentication, the real governance problem for human, NHI, and AI-driven workflows in banking and investing.
The article is written from a financial services perspective, but the structural issue is broader: if runtime authorisation is not continuously enforced, stolen credentials inherit whatever trust the login event created.
Key questions
Q: What breaks when phishing succeeds but post-login authorisation is weak?
A: The failure is not the login event itself, but the assumption that authentication is enough to govern what happens next. Once a stolen identity is trusted after entry, attackers can move through applications, data, and automated workflows until runtime controls stop them. That is why post-login authorisation is the real containment boundary.
Q: Why do stolen credentials create such a large risk in financial services?
A: Stolen credentials are dangerous in financial services because one login often reaches multiple applications, data sets, and delegated workflows. The account may also be linked to service accounts or automated processes, which turns a single phished identity into a wider access path. That is why post-authentication governance matters more than login success alone.
Q: What are the signs that runtime authorization is failing?
A: Look for inconsistent access behaviour across services, repeated policy logic in code, slow manual change cycles when rules move, and decision logs that cannot explain allow or deny outcomes. Those are signs the authorization layer is not operating as a shared control.
Q: Should organisations treat human and non-human SaaS access the same way?
A: They should apply the same governance standard, even if the operational details differ. Human users, service accounts, and application identities can all accumulate excess permissions, so approval, review, and revocation discipline should cover each of them. The key difference is frequency and automation, not whether least privilege applies at all.
Technical breakdown
Why authentication stops short of runtime authorisation
Authentication answers a narrow question: is this identity who it claims to be at the moment of login? It does not answer whether the identity should keep acting, or whether each request still fits policy once context changes. In the RBC scenario, the attacker needed only a believable pretext and the victim’s credentials to inherit session trust. That is why MFA, email security, and phishing awareness reduce exposure but do not close the post-login problem. Practical authorisation has to evaluate action, resource, and context after the login event, not just before it.
Practical implication: move from perimeter trust to action-level checks after authentication.
How compromised credentials expand across applications and NHIs
A single compromised human identity often becomes a bridge into broader machine access. In financial services, the human account may already be linked to APIs, service accounts, automation jobs, and data tooling that inherit or trust the same session. That is why the article treats NHI sprawl as an amplifier: once the front-door identity is accepted, the blast radius can extend across application, infrastructure, and data layers. The issue is not only credential theft, but downstream trust propagation through connected identities and workflows.
Practical implication: map which non-human identities inherit trust from human sessions and separate those decision paths.
Why policy-as-code matters for continuous enforcement
Continuous authorization only works if decisions are made at runtime using policy that can change quickly enough to match an active campaign. The article points to policy-as-code as the mechanism for that agility: rules are versioned, tested, and deployed like software, so enforcement can follow emerging abuse patterns without waiting for manual ticket cycles. Technically, this replaces static allow lists with decision points that inspect identity, action, data sensitivity, device posture, and location at each request. That is what makes authorization continuous rather than episodic.
Practical implication: define authorization as code so runtime decisions can change as fast as the threat.
Threat narrative
Attacker objective: The objective was to obtain usable authenticated access that could support further action inside financial services systems without tripping entry controls.
- Entry via spoofed RBC Direct Investing emails that used a W-8BEN renewal pretext to induce users to visit a fraudulent portal.
- Credential harvesting occurred when victims entered login details, personal information, and tax data into the fake site.
- Escalation followed when the attackers used the stolen credentials to log in and inherit the victim’s authorised session.
- Impact was broader than the phishing event itself because the compromised identity could operate until post-login controls intervened, if they existed at all.
Breaches seen in the wild
- Ivanti Connect Secure exploitation 2024: Two Ivanti VPN zero-days exposed user passwords, service account credentials, API keys and certificates on 1,700+ appliances, including at CISA.
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authorization gaps are now the decisive failure mode in financial services identity security. The RBC Direct Investing campaign shows that the sector’s hardest problem is no longer whether a user can be made to log in, but whether the identity can be constrained after login. Authentication is necessary, yet it is only a front-door control. The practitioner conclusion is that financial services identity programmes must be judged on runtime enforcement, not login success rates.
Continuous authorization is the control boundary that legacy IAM programmes still do not fully own. The article’s core point is that audit evidence for access policy is not the same as enforcement at the moment of action. Financial institutions often have policy documentation, MFA, and logging, yet still lack a decision layer that evaluates each request against context. The practitioner conclusion is that governance has to move from periodic attestation to live decisioning.
The authorization gap becomes a multiplier when human identities are connected to NHIs. In modern banking and investing environments, a compromised human session can touch APIs, automation, and AI-driven workflows that were never designed to re-check trust at each step. That is why NHI governance cannot sit outside IAM design. The practitioner conclusion is that identity architecture must treat human, service, and workload trust as one enforcement problem.
Post-phish risk in financial services is increasingly a policy design issue, not a detection issue. The article makes clear that detection after compromise is too late when attacker actions blend into legitimate access patterns. The named concept here is the authorization gap, which is the disconnect between identity proof at login and action control at runtime. The practitioner conclusion is that teams should redesign policy boundaries around actions, not accounts.
From our research library:
- U.S. fraud losses are projected to reach $40 billion by 2027.
What this signals
Authorization gap: The useful concept in this article is the disconnect between proving identity once and governing what that identity can do continuously. Financial services teams should treat that gap as a design defect, not a detection problem, because every inherited session expands the blast radius of a successful phish.
Point-in-time authentication remains necessary, but it is no longer the control that decides whether stolen credentials become a breach. The programme question now is whether policy can be enforced at the moment of each action across applications, data, and NHIs, including connected automation.
The RBC Direct Investing scenario is a reminder that phishing resilience is increasingly a runtime authorisation issue. Teams that only harden entry controls will still leave post-login trust, delegated access, and session inheritance exposed to abuse.
For practitioners
- Define post-login decision points Place authorisation checks at application, data, and workload boundaries so a stolen session is evaluated at each request, not trusted for the life of the login.
- Inventory inherited trust paths Map where human sessions automatically inherit access into APIs, service accounts, and AI workloads, then separate those trust paths from the initial authentication event.
- Move to policy-as-code Version, test, and deploy authorisation rules so response to active phishing or credential abuse can happen without waiting for manual change windows.
- Log every allow and deny decision Capture identity, action, resource, policy version, and context for each authorisation decision so post-incident review can reconstruct the first anomalous action.
Key takeaways
- The article argues that the main weakness exposed by the RBC Direct Investing phishing campaign is not credential capture itself but the lack of continuous control after login.
- Financial services environments are especially exposed because a single compromised identity can inherit access across applications, data, and non-human workflows.
- Closing the gap means authorising each action at runtime, not treating successful authentication as permission for everything that follows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on phishing-driven credential capture and the limits of login-centric defense. |
| NHI-05 — Overprivileged NHI | The article shows how trusted sessions can fan out into overbroad access across connected identities. | |
| NHI-10 — Human Use of NHI | Human credentials are shown cascading into NHI and workload access in financial services. | |
| Recommendation — Harden authentication paths, but do not assume login success ends the security problem. Reduce inherited access so a compromised session cannot traverse unnecessary trust boundaries. Separate human session trust from machine and workload authorization decisions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Continuous authorisation is the article's core control problem, not just initial authentication. |
| Recommendation — Enforce and review permissions at runtime rather than relying on a one-time login check. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The campaign follows credential harvesting and then uses the captured session to move through the environment. |
| Recommendation — Map phishing-driven credential theft to credential access and limit post-login lateral movement paths. | ||
Key terms
- Authorization Gap: The distance between what an authenticated identity can do and what it is actually permitted and proven to do in real time. For AI agents, the gap widens when decisions are made per action, at machine speed, and through workflows that expand faster than human review cycles.
- Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.
- Inherited Trust: Access or authority an agent effectively receives from a surrounding workflow, upstream agent, or human process rather than from its own direct permissions. This can make the agent appear properly scoped while its real operational reach is broader than the entitlement record suggests.
- Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org