September 2026 shows approval-layer attacks can outrun controls

At a glance

What this is: This monthly security beat says September 2026 losses reached $742.0M across 33 incidents, with attackers concentrating on approval mechanisms, signer trust, and governance authority.

Why it matters: It matters because IAM and PAM practitioners must treat approval systems, signer paths, and delegated governance as high-value control points, not background plumbing, especially where NHI credentials or admin powers can authorise irreversible actions.

By the numbers:

• Crypto lost $742.0M across 33 incidents in September 2026.
• Bitget's $387M hack and Liquid Network's $320M exploit account for about 95% of September's losses.
• The other 31 incidents added up to $35.0M.

Context

September 2026 was not defined by simple contract bugs alone. The month exposed a broader governance gap: attackers increasingly targeted the systems that decide whether a transaction, proof, or contract change should be trusted in the first place, which makes approval logic a security boundary rather than a back-office process.

That matters for identity security because approval paths often depend on privileged credentials, signer services, multisig administrators, vendor access, or delegated governance rights. When those controls sit above the application layer, compromise can turn a valid-looking request into an authorised action even when the underlying payload is malicious or forged.

Key questions

Q: What breaks when approval systems are compromised instead of the contract itself?

A: When approval systems are compromised, the attacker no longer needs to defeat the application logic. The system will often authorise forged withdrawals, invalid proofs, or governance changes as if they were legitimate. That means the highest-risk control is the component that certifies trust, not just the payload being executed.

Q: Why do signer and governance paths create such high impact when abused?

A: Signer and governance paths matter because they sit above the application and can authorise many downstream actions at once. If an attacker reaches that layer, a single credential, vote, or integration can become a force multiplier for theft, contract migration, or protocol takeover.

Q: What are the warning signs that approval-layer trust is failing?

A: Look for unusual transfer volumes, proof checks that rely on stale cache state, admin changes that arrive through indirect paths, and proposal activity that can reassign privileged control. Those are signs that the system trusts inherited authority more than current validation.

Q: How should security teams govern approval authority in digital asset systems?

A: Treat approval authority as privileged infrastructure. Separate who can request an action from who can bless it, minimise the number of components that can influence authorisation, and review any path that lets third parties, delegates, or governance votes override application-level controls.

Technical breakdown

How approval-layer attacks bypass contract-level controls

Approval-layer attacks succeed when the attacker does not need to break the business logic directly. Instead, they compromise the component that certifies legitimacy, such as a signer, governance module, verification cache, or privileged admin path. That shifts the trust boundary upward: the application sees an approved action, so downstream controls never question it. In practice, this creates a dangerous asymmetry. A low-cost compromise of a high-trust control plane can authorise high-value actions across wallets, bridges, or protocol administration. The core lesson is that security must model not only what the application does, but also who or what is allowed to bless the action.

Practical implication: Map every approval path and treat signer, governance, and verification services as tier-one assets.

Why third-party access can become a signing-path issue

The Bitget case shows a common pattern in modern identity abuse: the attacker does not only steal funds, they first inherit a path into an internal trust function through a third-party security product or high-level credential. Once inside, forged instructions can look routine to the system that authorises transfers. This is a classic privilege problem, but the consequence is more severe because the privileged actor is not a person alone; it may be a service account, admin integration, or security tool with effective signing influence. That is where IAM and PAM discipline matters most: if a credential can influence approval, it belongs in the strongest control tier.

Practical implication: Inventory every credential and integration that can influence approval decisions, not just those that hold money.

Governance authority can outrank application-level multisig design

The Neutron pattern shows that a well-designed application control can be overridden by a higher governance layer. A multisig may protect contract actions, but if chain governance can reassign admin rights above it, the real control sits elsewhere. This is the governance-stack problem: organisations often secure the application they can see while underestimating the authority above it. When a vote, policy change, or delegated admin path can migrate contracts or alter execution rights, the security model must include political and procedural abuse, not just technical compromise. Approval security therefore spans both cryptographic control and governance legitimacy.

Practical implication: Assess which authority can supersede application controls and add that layer to threat modelling.

Threat narrative

Attacker objective: The attacker aimed to turn approval authority into asset theft or protocol control without having to defeat the underlying application logic.

1. Entry occurred through compromise of a third-party security product or privileged verification path, giving the attacker access to a high-trust internal system.
2. Credential or authority abuse followed when forged withdrawal requests, invalid proofs, or governance actions were accepted as legitimate by approval mechanisms.
3. Impact came from rapid asset movement, unauthorised minting, or contract reconfiguration that converted trust failure into direct financial loss.

NHI Mgmt Group analysis

Approval-layer compromise is now the decisive security problem in digital asset systems. The article shows that attackers no longer need to defeat the transaction itself when they can compromise the authority that certifies the transaction. That shifts the real security boundary to signers, governance modules, and verification caches, which are often treated as support systems rather than critical control planes. Practitioners should model approval logic as a privileged trust service, not an implementation detail.

Delegated authority is a governance risk, not only an operational convenience. The Bitget and Neutron cases show that a credential, security product, or vote can become a hidden path to authorise destructive action. This is directly relevant to IAM and PAM because machine credentials, admin integrations, and service accounts can all sit inside approval chains. Practitioners should assume that any actor able to influence authorisation outcomes is part of the privileged estate.

Control-plane trust must be validated above the contract layer. Liquid's verification cache and Neutron's governance authority illustrate two different ways the same failure mode appears: a higher trust decision is accepted without sufficient revalidation. This is the kind of issue that conventional application controls miss because they focus on the payload, not the certifying system. The practical conclusion is to audit the trust tier above the business logic as aggressively as the business logic itself.

Approval-path abuse is becoming a repeatable pattern, not an isolated class of bugs. Quantstamp's month-end review and DefiLlama's governance-attack comparison suggest that attackers are learning where trust is easiest to purchase or spoof. The field needs sharper control over approval issuance, admin migration, and proof verification, especially where non-human identities or delegated systems can act with human-equivalent authority. Practitioners should elevate approval governance into the core risk programme.

Approval surface: the layer that certifies trust is now the highest-value target. That concept is useful because it names the common failure across signers, governance votes, and verification caches. Once the approval surface is compromised, the attacker does not need to persist in the application itself; the system will authorise the harm on their behalf. Security teams should build threat models around that surface explicitly.

What this signals

Approval systems are now part of the asset perimeter. In digital asset environments, the control that decides whether an action is legitimate can be more valuable to attackers than the action itself. That should push approval-path review, signer-path monitoring, and governance override analysis into routine security governance rather than periodic post-incident cleanup.

Identity teams should treat privileged integrations as part of the signing chain. A security product, admin console, or service account that can influence transfer approval is not merely adjacent to the control plane; it is inside it. The practical consequence is that PAM and NHI programmes need an explicit view of which non-human identities can bless high-impact actions.

Approval surface: the set of systems, credentials, and governance mechanisms that can validate or supersede a high-risk action. Once teams name that surface, they can test it directly, instead of assuming that protecting the underlying contract or wallet is enough.

For practitioners

• Map the approval surface Inventory every system that can bless a transaction, proof, contract migration, or admin change, including signers, governance modules, caches, and vendor-integrated controls.
• Separate signing authority from upstream tools Remove direct paths from third-party products and routine admin credentials into systems that authorise transfers or contract changes, and require explicit, narrow delegation.
• Revalidate trusted decisions at the point of approval Do not rely on cached verification or inherited trust when the action is economically destructive or governance-changing; force a fresh decision before execution.
• Model governance override paths as privilege escalation Test whether a vote, policy update, or admin reassignment can supersede application-level controls, and treat that path as part of the privileged estate.
• Add signer-path monitoring to incident detection Alert on unusual withdrawal volumes, proof verification anomalies, admin migration proposals, and any approval request originating from a newly trusted path.

Key takeaways

• September's losses show that attackers are targeting the layer that approves transactions and governance changes, not only the code that executes them.
• A small number of incidents drove most of the damage, which indicates that high-trust control points create outsized blast radius when they fail.
• Security teams need to model signer paths, verification caches, and governance overrides as privileged infrastructure and monitor them accordingly.

Key terms

• Approval Surface: The approval surface is the set of systems, credentials, and governance mechanisms that can validate, authorise, or override a high-risk action. In digital asset and identity-heavy environments, this surface often includes signers, admin integrations, verification caches, and delegated governance paths.
• Signer Path: A signer path is the route a request takes to reach the system that authorises execution, such as a wallet signer, transaction gate, or privileged approval service. If that path is compromised, the attacker may not need to break the underlying application logic at all.
• Governance Override: A governance override is any higher-level control that can supersede a local security mechanism, such as a contract setting, multisig policy, or application rule. It becomes a security risk when authority above the application can reassign privileges or authorise destructive changes without sufficient resistance.
• Verification Cache: A verification cache stores prior trust decisions so a system can avoid repeating expensive checks. It improves performance, but if the cached decision is wrong or can be manipulated, the system may accept invalid inputs as already verified and create a silent security failure.

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. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.