The signer should sign what was approved, and nothing else.

Four groups of questions, taken from our withdrawal-path checklist and vendor access checklist. Answer from evidence: a config, a log, a test. If you cannot show it, the answer is “unknown”, and unknown counts as no.

HSM and MPC set-ups raise more. For an HSM: are signing keys generated inside it and non-exportable (3.8), do administration actions need a quorum and get logged where the administrators cannot edit them (3.9), and is the signing policy enforced inside the HSM or its signing application (3.10)? For MPC: do the parties that hold shares run in independent administrative domains (3.11), does each node verify what it signs (3.12), and are share refresh, node replacement, threshold changes and recovery governed, tested and alerted on (3.13)? For multisig and MPC alike: are owners, thresholds, modules, delegates and policies exported and reviewed regularly, and is a change to any of them an alert? (3.7) And is there a documented key ceremony, with evidence kept, for generation, rotation and recovery? (3.5) Neither checklist is an audit, a certification or legal advice. Answering yes to everything does not mean the path is secure.

Public records of four withdrawal-path incidents leave the same five questions open. For three of the four, the record says nothing firm about what the approvers were shown. See what the record does not say. Our September 2026 note on where custody fails looks at the process and integration around the keys, not the cryptography.

• A map of the signing path. Every system, role and vendor between the client instruction and the broadcast, with the trust each one places in the last.
• Findings you can act on. Each states a title; a severity with a one-line justification; the affected component; the business rule it breaks; the impact in money terms where we can size it; reproduction steps; a proof of concept that fails before the fix and passes after; the recommended fix; and how to verify it. We separate confirmed findings from suspicions.
• Changes to make. Specific changes to limits, approval rules, signing policy and vendor access, each with how to verify it.
• A list of what was not reviewed, and a fix review in which we re-check the fixes you make.

An example of the format is in the sample report. It is a demonstration on a synthetic system, not client work.

The sample report does not cover custody. This finding sits on the ledger side, and comes from the synthetic sample. It shows what reaches a withdrawal path when nobody checks the state it acts on.

Two requests in parallel, each for the whole balance.
Sequentially, the second is rejected.
In parallel, both are accepted.
Balance afterwards: -50,000 USDC

• Smart-contract code. We refer standalone contract audits to specialist firms.
• General web-application penetration testing.
• Red-team and threat-led penetration testing (TLPT) exercises.
• Round-the-clock incident response.
• Certification audits, and legal or regulatory opinions.
• The cryptographic design of an MPC or signature scheme; we review how it is configured, integrated and operated.
• Anything outside the written scope list.

We review; you fix. We do not change your live systems or move funds. We can bring in a partner for the items above, and say so plainly in the proposal. Every statement of work lists its own exclusions. A review of one part of your system says nothing about the parts we did not look at.

• Scoping call. You tell us what you run, the custody model, the signing set-up and what is prompting the review.
• Conflict check, mutual NDA and written scope. Before any testing we run a conflict check, sign a mutual non-disclosure agreement and agree a written scope list. Nothing outside it is touched.
• Review, with early warning. A critical finding goes to your named contact as soon as it is confirmed, not at the end.
• Report and readout. A written report and a session with your engineers and risk owner.
• Fix review. We re-check the fixes you make.

Price is set on a scoping call, fixed per scoped deliverable and agreed in writing before work starts. Scope, assumptions, acceptance criteria and change control go in the proposal.

• A named contact who can authorise scope and receive critical findings.
• Architecture documents and read access to the code or design of the withdrawal path.
• Engineer time for walkthroughs, usually a few hours per person across the engagement.
• An agreed test environment, and the vendor contacts we may speak to, with your consent.
• Written authorisation for each system in scope.

A deebug report is evidence for your own compliance work. It is not an audit opinion, a certification, a regulatory approval or legal advice. deebug holds no certifications and does not claim any. Where a regulator requires a certified or accredited tester, we say so up front and propose a partner. Ask counsel to review anything you rely on.

Japan

• FSA cybersecurity policy (final, 3 April 2026). The FSA says that from the 2026 supervisory year it will ask all crypto-asset exchange operators to run the cybersecurity self-assessment (CSSA). The policy states no deadline, and we found no CSSA form or deadline. Whether this is a legal obligation or an administrative request is not established.
• Same policy. External verification of “system-risk management, signing-key management and so on” is an item the FSA says it will consider when it raises its Supervisory Guidelines. It is not yet a requirement. We found no revised guideline.
• JVCEA rules (in force 1 July 2026). The system-risk rule and guideline cover private-key information management and a duty of periodic vulnerability assessment and penetration testing. JVCEA rules bind JVCEA members. We did not find a JVCEA rule that names system vendors as regulated parties.
• FIEA amendment. Japan's 2026 amendment to the Financial Instruments and Exchange Act (Act No. 64, promulgated 23 July 2026) creates a notification regime for providers of customer-asset management systems. Whether a given provider is covered is a question for counsel.

Japan: checked against primary documents on 11 November 2026, and the enacted text of Act No. 64 on 13 November 2026. It is our reading, not legal advice.

EU

Neither MiCA nor DORA asks for a withdrawal-path review by name. They ask for secure ICT systems, controlled outsourcing, safe custody and independent testing. A review can supply evidence. See EU MiCA and DORA for the full table.

The ESMA action is supervisory, not a testing mandate. The authorisation standard asks for a third-party cybersecurity audit “if available”, so it is not a stated condition of authorisation. Smart-contract risks in that action are outside what we review by default; we refer standalone contract audits. Under DORA, TLPT applies only to entities the competent authority identifies, and we found no published list of crypto-asset service providers identified.

EU: read from the Official Journal texts and ESMA pages on 11 and 12 November 2026, as published, not consolidated. We have not checked later amendments. Not legal advice.