By CRYPTOVERSE Legal Consultancy
Three approvals, one person in control
A crypto company preparing its FCA authorisation application describes its wallet security confidently.
“We use multi-party computation. Every withdrawal requires three approvals.”
During an internal review, the compliance team asks who can change the approval rules.
The answer: the chief technology officer.
Who can reset the approvers’ accounts?
The same person.
Who controls the emergency recovery process?
Again, the same person.
The company has several approval steps, but its administrative arrangements could allow one individual to bypass them.
This is why cybersecurity preparation must examine how controls operate together. Naming a sophisticated wallet technology does not explain who can ultimately move assets, alter permissions or override safeguards.
What cybersecurity evidence should a crypto firm prepare for FCA authorisation?
A crypto applicant should be able to explain its security risks, the controls protecting customer assets and information, who holds sensitive access, and how the business will detect, contain and recover from incidents.
The FCA’s FG26/6 guidance on cryptoasset operational resilience identifies private key compromise, weak access controls and code vulnerabilities among relevant risks. It expects proportionate cyber and technology controls, secure processes for safeguarding cryptographic access, and evidence of monitoring and testing. fca.org.uk
The practical objective is a coherent account of the firm’s security arrangements, supported by evidence. A policy, architecture diagram and testing report should describe the same operating model.
Understand which requirements apply
Cybersecurity obligations depend on the firm’s activities, structure and applicable rules.
A crypto custodian must consider the requirements protecting the means of access to customer cryptoassets. An intermediary that does not safeguard assets still needs to assess risks affecting order transmission, customer information and its service dependencies.
Under the final custody rules, CASS 17.4.4R–17.4.6R require robust arrangements protecting means of access throughout their lifecycle, together with prompt identification and resolution of relevant incidents.
CASS 17.4.8R–17.4.10R require accurate means-of-access records, including how control is exercised, with five-year retention from creation or the latest modification, whichever is later. The record must not reproduce the means of access itself.
CASS 17.4.11R requires policy and procedures documents explaining compliance in clear, non-technical terms, reviewed at least annually. These are final rules for the new regime; their application must be assessed against the relevant commencement and scope provisions. fca.org.uk
A security review should therefore begin with the proposed activities and custody arrangements, then map the applicable obligations.
Explain wallet security across the entire lifecycle
“Assets are held in cold storage” is an incomplete description.
A useful wallet security assessment follows what happens from initial setup to eventual retirement:
| Stage | Questions to resolve |
| Creation | Who establishes keys or signing shares, and how is the process controlled? |
| Storage | Where are sensitive materials held, and who can access them? |
| Use | How are transaction instructions checked, authorised and signed? |
| Change | Who can alter signers, thresholds, withdrawal policies or recovery settings? |
| Recovery | What happens if a device, provider or authorised person becomes unavailable? |
| Retirement | How are obsolete credentials and residual access removed? |
For application preparation, we recommend documenting both ordinary operations and exceptional procedures.
Emergency access deserves particular attention. A secure everyday workflow may lose its effectiveness if a recovery procedure grants broader powers without adequate supervision.
MPC and multisignature arrangements require careful analysis
Multi-party computation and multisignature technologies can distribute signing authority. Their effectiveness still depends on configuration, account administration, recovery arrangements and genuine independence between participants.
The FCA’s guidance lists these technologies, hardware security modules and other approaches as examples of practices firms may use. It also cautions against centralising risk through their implementation. These examples do not prescribe one mandatory wallet architecture for every applicant. fca.org.uk
Our practical recommendation is to ask:
Could one compromised identity, administrator or recovery process defeat several apparently separate controls?
That question often reveals more than the number of nominal signers.
Make privileged access visible
Some of the most consequential permissions sit outside the wallet itself.
An individual might be unable to sign a transaction but still be able to change withdrawal destinations, modify a screening configuration, deploy new software or disable alerts.
We recommend maintaining a permissions assessment covering:
- Wallet and signing administration.
- Cloud infrastructure and identity systems.
- Customer account recovery.
- Deployment and production changes.
- Transaction screening settings.
- Logging and security monitoring.
- Provider consoles and emergency credentials.
For each sensitive permission, identify the holder, business justification, approval process and review frequency.
Practical safeguards may include individual accounts, least-privilege access, strong authentication, time-limited elevated permissions and independent review of consequential changes. The appropriate combination depends on the firm’s risks.
Access removal should also cover contractors, outsourced personnel and group employees. Disabling a corporate email account may leave API credentials or provider access intact.
Assess transaction controls separately from key protection
A key can remain technically secure while the system signs a harmful instruction.
For example, a compromised application might submit an unauthorised withdrawal through an otherwise legitimate signing process.
A practical assessment should examine:
- How the firm establishes that an instruction is genuine.
- How destination changes are verified.
- Whether unusual amounts or patterns trigger escalation.
- How duplicate instructions are detected.
- How transaction details are checked before signing.
- Which controls remain effective if an application account is compromised.
This connects cybersecurity with operations and customer asset protectionContact CRYPTOVERSE .
The application narrative should explain how the firm prevents an attacker from turning access to one system into authority over customer assets.
Examine providers and group dependencies
Using an established wallet vendor or a group security team can support a strong operating model. The applicant still needs to understand its own responsibilities.
Where the relevant outsourcing provisions apply, SYSC 8.1.6R retains the firm’s regulatory responsibility and prevents outsourcing from delegating senior personnel’s responsibility. The precise application differs by firm classification.
For legal and operational review, we recommend examining:
- Which party can change security configurations.
- How quickly the applicant receives incident information.
- Whether evidence and logs remain accessible.
- Who authorises emergency action.
- Which subcontractors create further dependencies.
- How access and assets are managed when the relationship ends.
A provider certificate can contribute evidence. Management should still understand its scope, exclusions and relevance to the services the applicant actually uses.
Prepare an incident response plan people can execute
An effective plan gives staff clear decisions to make under pressure.
Consider a suspicious withdrawal alert. The firm needs to establish who can pause affected transactions, whether compromise extends beyond one wallet, and which records must be preserved.
We recommend structuring the response around five tasks:
- Assess: establish the known facts, affected services and potential customer impact.
- Contain: restrict compromised access and prevent further harm.
- Preserve: protect logs, transaction records and other evidence.
- Recover: restore trustworthy systems and verify outstanding instructions.
- Communicate: coordinate management, customers, providers and relevant authorities.
The sequence may overlap. The plan should support timely action while recording decisions and uncertainty.
Restoring availability is only part of recovery. The firm should also establish that systems and records are reliable before resuming sensitive activity.
Build regulatory reporting into the response
Regulatory notification should be assessed during the incident.
The FCA’s current reporting guidance links notification to Principle 11 and SUP 15.3, with indicators including material service disruption, unauthorised systems access and significant data loss.
It also identifies a new operational incident reporting framework commencing 18 March 2027. Applicants should assess the framework applicable to their status and intended authorisation date, including reporting thresholds and whether standard or enhanced reporting applies. Other reporting obligations may arise independently. FCA
A useful internal reporting matrix identifies:
- The decision-maker and deputy.
- The legal or regulatory trigger.
- The reporting channel.
- Information needed for the initial notification.
- Ownership of subsequent updates.
Avoid treating the date of the expanded crypto regime as the commencement date for every related reporting requirement.
Test security and response capabilities
Testing should examine whether the firm’s controls withstand relevant threats and whether staff can respond effectively.
For firms within scope, SYSC 15A.5 requires scenario testing against severe but plausible disruption, followed by lessons learned and necessary improvements.
Practical exercises could include a compromised administrator account, a wallet provider outage or unauthorised changes to withdrawal settings.
Record what happened, which controls worked, where decisions stalled and how identified weaknesses will be resolved. Preserve the distinction between completed improvements and planned work.
Returning to the opening scenario
The company discovers that its approval structure depends heavily on one administrator.
It revises the permissions model, separates sensitive configuration changes from routine administration and strengthens oversight of emergency recovery. It then tests whether a compromised administrator could still bypass the withdrawal safeguards.
The resulting evidence explains how authority is distributed and how the business responds when a control fails.
That is a more useful basis for an FCA application than the statement, “We use MPC.”
How CRYPTOVERSE can support your application
CRYPTOVERSE is a specialist legal and regulatory firm for UK FCA cryptoasset authorisation support.
We can help align your security policies, custody arrangements, outsourcing contracts, incident procedures and application narrative with the relevant regulatory requirements, working alongside your technical specialists.
Contact CRYPTOVERSE to review whether your cybersecurity evidence clearly demonstrates control over your proposed UK crypto services.
FAQs
1. Does the FCA require every crypto firm to use MPC?
No. Multi-party computation (MPC) is one example of a security approach. Firms should select and implement security arrangements that address their specific risks, including key management, access controls, recovery procedures, and the possibility of administrative compromise.
2. What cybersecurity evidence is required for FCA crypto authorisation?
Evidence may include wallet security policies, access permissions, key-management procedures, transaction controls, incident response plans, provider oversight arrangements, and security testing records. The appropriate evidence depends on the firm’s activities, custody arrangements, and applicable regulatory requirements.
3. Is an independent cybersecurity certification sufficient for FCA authorisation?
No. Certification can support an application, but it does not automatically demonstrate that the firm’s security controls are effective. Applicants should also provide evidence of their actual configurations, access restrictions, testing results, and remediation of identified weaknesses.
4. Do crypto firms that do not hold customer assets need cybersecurity controls?
Yes. Firms that do not safeguard customer assets should still assess cybersecurity risks affecting their systems, customer information, transactions, and third-party service providers. The specific controls and regulatory obligations depend on the firm’s activities.
5. Should FCA crypto application documents contain private keys or recovery secrets?
No. Application documents should explain how cryptographic access is secured without disclosing private keys, credentials, or recovery secrets. Sensitive access information must remain protected, and relevant records should follow the applicable regulatory requirements.