Recently, nearly half of crypto losses have come from failures in permissions and operations, and the focus of security is shifting from contract auditing to identity, authorization, and operational trust.

Written by: Ken Wong (Founder of BitDATA PayFi Infra, former cybersecurity researcher)

Translated by: AididiaoJP, Foresight News

For many years, the crypto industry has primarily viewed security as a smart contract issue. This made sense for a long time. Smart contracts, private keys, audits, and wallet security remain essential.

However, a recent wave of events suggests that the next major security crisis may not arise from cryptography being compromised. It may be more insidious: the system executes the operations it is authorized to perform correctly, but the authorization itself should never have been trusted from the beginning.

1. Loss Structure Has Changed: Nearly Half Is No Longer "Code Vulnerabilities"

The Hacken "2026 Q3 Security and Compliance Report" shows that during the quarter, the industry experienced 107 incidents, resulting in losses of $1.18 billion, a 55% increase over the previous quarter. More importantly, the structure of the losses is noteworthy: 48% came from smart contract vulnerabilities, while 40% came from access control and operational failures.

This means that nearly half of the losses are no longer traditional code bugs, but rather issues with identity, permissions, signature processes, or broader operational trust boundaries.

This distribution is crucial. Smart contract vulnerabilities can often be remedied through better auditing, formal verification, and stricter engineering discipline. However, access control and operational failures require an entirely different approach.

It forces the industry to answer several more difficult questions: Who has the authority to move funds? Which systems inherit signing rights? What happens if a "trusted" service turns malicious? How much damage can a compromised identity cause?

This is no longer purely a Web3 programming issue; it has become a financial infrastructure issue.

2. Attack Surface Spillover: Usability Is Also Security

Crypto security is not isolated. It exists within a global threat environment, where the scale, speed, and operational flexibility of attacks are on the rise.

The Cloudflare "2026 Q3 DDoS Threat Report" states that during the quarter, there were mitigations of 18.2 million network layer DDoS attacks and 14.4 trillion HTTP DDoS requests, averaging about 8,226 network layer attacks per hour. Short-term, low-bandwidth attacks surged by 208%, DNS amplification attacks increased by 215%, and UDP flood attacks grew by 122%. Attack targets are also becoming more dispersed.

This data signifies two things for crypto and PayFi.

First, network risks are no longer focused solely on high-value targets like exchanges. Banks, payment processors, internet infrastructure providers, telecom operators, and service suppliers are all part of an ever-expanding attack surface.

Second, it underscores a fact that many crypto projects still underestimate: usability, resilience, and operational continuity are equally security issues.

Security systems must not only prevent theft but also remain trustworthy under pressure, rapidly contain abuse, and facilitate secure recovery.

3. Key Details of the Binance Incident: Private Key Security Is Not Equal to Transaction Security

On October 29, 2026, Binance revealed in a security incident statement that approximately $6.34 billion worth of digital assets were affected, with about $2.85 billion frozen or intercepted; as of October 31, 98% of the affected token assets had been recovered.

However, from a security architecture perspective, the more critical aspect is the attack vector: the attacker unauthorizedly accessed the internal wallet transaction signing service, bypassing the regular withdrawal process.

This detail is more important than the amount. It illustrates that protecting private keys does not equate to safeguarding transaction rights.

Systems can lock the keys in fortified infrastructure, set up internal signing processes, or isolate wallets. But as long as the attacker controls a system or service that already has legitimate transaction rights, being "cryptographically valid" is not enough.

A valid signature does not mean an effective commercial decision. This is precisely the distinction the industry must now take seriously.

4. Authentication, Authorization, and Transaction Legitimacy Are Three Separate Matters

In digital finance, there are at least three questions that must be separated:

• Who is initiating the request? This is identity authentication.
• What is this identity permitted to do? This is authorization.
• In the current context, should this specific transfer be allowed? This is transaction legitimacy.

Too many systems only address the first two. If the API credentials are valid, the signer has approved, and the workflow is technically authorized, the transaction is treated as trustworthy. This assumption is becoming increasingly dangerous.

A stolen session token can bypass password verification; a compromised supplier can serve as an entry point; an over-privileged internal service can become a transaction channel; even a legitimate signer can approve an illegitimate payment.

Thus, the next phase of crypto security must extend from asset protection to permission control. The issue is no longer just "Can the attacker access the system?" but more importantly: After a trusted identity is compromised, what can it actually do?

This is the more meaningful resilience metric.

5. The More Complex PayFi Becomes, the Clearer the Permission Boundaries Must Be

As digital assets become more deeply connected with banking channels, virtual accounts, OTC settlements, cards, merchant acquiring, and programmable payments, trust boundaries become more complex.

In the modern PayFi tech stack, a single transaction may flow through wallets or custodians, API gateways, orchestration layers, compliance or risk control engines, signature or settlement components, and one or more banks or payment partners. Each layer has its own permissions, dependencies, and operational assumptions.

The engineering challenge is no longer merely "transferring money faster," but ensuring that permissions, responsibilities, risk control, and auditability remain consistent throughout the payment lifecycle.

This is even more crucial when AI agents and automated services act on behalf of users or enterprises. Machine identities may be allowed to initiate requests, but that does not mean they should be permitted to approve new payees, expand limits, or disburse funds without independent verification.

A machine identity does not equate to financial permissions. Delegated permissions should not turn into unlimited permissions.

6. Shifting from Asset Protection to Permission Control

The industry still needs better smart contracts, better auditing, and better key management.

But the latest trends demonstrate: The next major security failure may not be due to cryptography being compromised, but rather to the misuse of trusted permissions.

Thus, the next phase of crypto and PayFi security should prioritize four things simultaneously:

• Permissions must be narrowed. Identities and services should have only the minimum rights.
• Transaction-level controls must keep pace. High-risk actions require contextual reviews, limits, and independent checks.
• Operational resilience must be measurable. Security should not only consider what has been blocked but also what happens when trusted components fail.
• Auditing and accountability must be reliable. Systems must leave a trail indicating who initiated, who authorized, and who executed the flow of funds.

This is precisely where cybersecurity, financial infrastructure, and programmable payments begin to converge.

7. Questions the Industry Needs to Answer

If an attacker gains access to a trusted system identity or controls an authorized transaction service, how much protection remains?

Further: For smart contract auditing, identity control, transaction-level authorization, and operational resilience, what should the next phase prioritize?

My answer is that these are not mutually exclusive but complementary. However, the order is important because capital, engineering time, and managerial attention are limited.

The next security crisis will not wait for the industry to finish its debates.