TL;DR: Revolut and Swiss Bitcoin Pay breaches exposed customer data through social engineering and an unresolved platform compromise, according to FYEO, showing that Web3 security failures often start with human verification gaps and supply chain exposure rather than smart contract code alone. Operational security, identity checks, and data minimisation now matter as much as protocol hardening.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on FYEO's blog post: Revolut and Swiss Bitcoin Pay breaches show how social engineering and platform compromise can expose sensitive Web3 customer data even when funds are not stolen.
Why it matters: This matters to IAM, PAM, and NHI practitioners because identity proofing, request verification, and data access governance now sit inside the trust boundary for both fintech and Web3 operations.
By the numbers:
- Revolut said nearly 700 customers were affected by the data exposure, according to FYEO.
Context
Social engineering works because attackers target verification processes, not just technical controls. In identity-sensitive environments, a convincing request can move through email, support, or operations workflows faster than governance can catch up, especially when access to customer data is handled as a routine business process rather than a high-risk identity event.
This FYEO analysis ties Web3 breaches back to the same control problem that appears across IAM, PAM, and OAuth app governance: who is allowed to request data, how that request is validated, and what happens when a trusted channel is forged.
Key questions
Q: How should security teams stop social engineering from turning into data disclosure?
A: Treat any request for sensitive personal or financial data as a privileged event. Require independent verification, separate approval authority, and logging that can be reviewed after the fact. The goal is to make a forged request fail even when it looks operationally routine.
A: Exposed identity data enables convincing impersonation. Names, addresses, phone numbers, ID images, bank details, balances, and transaction history give attackers enough context to craft believable phishing and social engineering messages that appear to come from the exchange. That makes the breach a fraud multiplier, because the stolen information can be reused to pressure users into handing over credentials or approving transfers.
Q: What are the signs that a trusted request workflow is failing?
A: Look for approvals that rely on sender identity alone, exceptions handled outside standard channels, and staff who cannot explain why a disclosure was approved. Those are strong indicators that the workflow is being trusted more than it is being verified.
Q: What should teams do when a third-party or support channel can access customer records?
A: Reassess the workflow as if it were an external privilege path. Limit the data exposed through that channel, enforce least privilege, and require explicit ownership for every access route that can reveal regulated or sensitive information.
Technical breakdown
How pretexting bypasses identity verification workflows
Pretexting succeeds when a target believes the requester is authorised to ask for sensitive information. In these incidents, the attacker used a believable government-style request, which is effective because many organisations optimise for speed and service quality, not adversarial verification. The failure is rarely a single missing control. It is usually a chain of weak identity proofing, informal exception handling, and staff reliance on visual cues such as sender domains. In regulated environments, that turns a human approval step into an attack surface. See the NHI governance angle in identity-bound request handling.
Practical implication: Treat sensitive data release requests as privileged actions and require out-of-band verification before any disclosure.
Why supply chain exposure in Web3 often starts with delegated trust
Web3 platforms frequently depend on third-party services, hosted infrastructure, and operational tooling that broaden the trust boundary. When those dependencies are not tightly governed, an attacker does not need to break the cryptography of the protocol itself. They can target the surrounding operational layer, including support systems, email workflows, and server infrastructure. That is why supply chain attacks and social engineering often converge: one abuses inherited trust, the other abuses human trust. The result can be data exposure even when core assets remain intact. See the CI/CD and third-party identity risk in [[L3|pipeline identity security]]. See the CI/CD Pipeline Identity Security Guide.
Practical implication: Map every external dependency that can disclose customer data and apply least privilege to each trust relationship.
Why exposed personal and transaction data creates lasting downstream risk
The most important harm in these incidents is not immediate fund loss. It is the durable linkage of identity, banking, and transaction data that enables later fraud, phishing, and account takeover attempts. A breach that exposes email addresses, IBANs, and blockchain activity gives attackers enough context to build highly credible lures. From an identity governance perspective, the risk persists after the incident because the data cannot be retracted. That means retention, minimisation, and access controls are part of incident prevention, not only privacy compliance. See the data minimisation and access governance model in [[L2|AI supply chain security]]. See the AI Supply Chain Security and AI-BOM Guide.
Practical implication: Reduce retained sensitive attributes so a single disclosure does not become a long-lived fraud enablement event.
Threat narrative
Attacker objective: The attacker wanted to obtain sensitive customer and financial data that could be reused for fraud, phishing, and identity abuse.
- Entry occurred when the attacker used a convincing government-style pretext to get a sensitive data request treated as legitimate.
- Credential or access abuse followed when internal staff or processes released customer records through a trusted channel without sufficient verification.
- Impact was the exposure of personal, financial, and transactional data that can feed phishing, identity theft, and further fraud.
Breaches seen in the wild
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
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
Social engineering has become an identity governance failure, not just a training problem. These incidents show that attacker success depends on whether an organisation can distinguish legitimate authority from manufactured authority. When approval pathways rely on familiarity, email legitimacy, or urgency, the control environment is already weakened. Practitioners should treat request validation as part of identity security, not as a soft process concern.
Web3 security is still governed by the trust boundaries around the protocol. Smart contract correctness does not prevent compromise in support workflows, hosted infrastructure, or vendor-connected processes. That is why the operational perimeter now matters as much as the code perimeter, especially when customer data can be exposed without direct asset theft. Practitioners need to govern the surrounding identities and access paths, not only the chain itself.
Data exposure in crypto and fintech is a standing fraud-enablement condition. Email addresses, IBANs, passports, and transaction histories are enough to support long-tail phishing and impersonation campaigns. Once disclosed, those attributes cannot be rotated back into safety, which makes minimisation and retention control a governance issue. The reader should assume that every exposed identity attribute expands the attack surface after the incident ends.
Operational security debt is the named concept here: a weak trust process accumulates into breach exposure. The issue is not simply that one attacker got lucky. It is that the organisation allowed a high-risk request to pass through a normal business workflow without adversarial friction. That creates a repeatable path for future abuse unless identity proofing and release authority are redesigned as security controls. Practitioners should focus on the process that granted trust, not only on the attacker who exploited it.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
Verification friction is now a control, not a customer-service defect. If a process can be manipulated by a convincing external request, it is already too permissive for sensitive data release. The practical shift is to design verification so that legitimacy must be proven twice, not assumed once.
Web3 organisations should treat identity data and transaction context as a single risk surface. The breach pattern here is not just exposure of records, but exposure of the context that makes later fraud credible. That means security teams need to align data governance, request validation, and incident response instead of treating them as separate problems.
For practitioners
- Implement out-of-band verification for sensitive requests Require a second channel and a second approver before any release of customer identity or financial data, especially when the request claims regulatory authority.
- Classify data release as a privileged workflow Treat disclosure of passports, transaction histories, IBANs, and similar records as a privileged action with approval logging and exception review.
- Reduce the retained data footprint Keep only the customer attributes required for operations and shorten retention where business or regulatory needs allow.
- Scope third-party and support access tightly Review every external service, support path, and delegated workflow that can view or export customer data, then remove standing access that is not essential.
- Test fraud and phishing assumptions after disclosure Assume exposed identity attributes will be reused in targeted scams and update user warnings, monitoring rules, and response playbooks accordingly.
Key takeaways
- These breaches show that social engineering can bypass technical controls when identity verification workflows are too trusting.
- The impact extends beyond immediate fund safety because exposed identity and transaction data can drive later phishing and fraud.
- The most effective preventive control is not just user awareness but privileged request governance, out-of-band verification, and data minimisation.
Related NHI Mgmt Group resources: SaaS-to-SaaS and OAuth App Governance Guide · CI/CD Pipeline Identity Security Guide · AI Coding Agents Security Guide · Palo Alto Networks Salesforce data theft 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001; TA0006 — Initial Access; Credential Access | The article centres on social engineering and trust abuse that enabled sensitive data disclosure. |
| Recommendation — Map the request path to TA0001 and TA0006, then hunt for places where trusted channels can be forged. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Sensitive data release depends on who can approve and disclose records. |
| Recommendation — Apply PR.AA-05 to constrain who can authorise customer data disclosure and review exceptions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Delegated access and support workflows are central to the exposure path described. |
| Recommendation — Use CIS-5 to inventory and remove unnecessary accounts, roles, and delegated access paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The incidents show the risk of overbroad access to customer records and support channels. |
| Recommendation — Enforce AC-6 so only narrowly scoped roles can view or release sensitive customer data. | ||
| GDPR | Art.32 — Security of Processing | The breaches exposed personal data and raise processing-security concerns. |
| Recommendation — Use Art.32 to justify strong verification, minimisation, and access protection for personal data. | ||
Key terms
- Social Engineering: Social engineering is the use of deception, urgency, and authority to persuade a person to reveal information or take a risky action. It targets human decision-making rather than software defects, and often turns legitimate identity workflows into the attack path.
- Pretexting: Pretexting is a social engineering technique where an attacker invents a believable story to get information or trigger an action. It often impersonates support staff, vendors, or executives, and succeeds when the target accepts the story without independent verification.
- Operational security: Security that depends on procedural and administrative controls rather than cryptographic strength alone. In HSM governance, this includes network restriction, personnel vetting, and update oversight, which can reduce risk but do not alter the underlying trust root.
- Data Minimization: Data minimization is the practice of limiting personal data collection to what is adequate, relevant, and necessary for a specific purpose. It reduces exposure by shrinking what is gathered, transferred, retained, and processed. Strong minimization depends on careful form design, purpose review, and strict collection discipline.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. For practitioners responsible for access, verification, and privileged workflows, it provides a common control language for reducing identity-driven risk.
Published by the NHIMG editorial team on October 27, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org