For an exchange or wallet provider, a server is never just a server. It is the place where signing services, withdrawal queues, matching engines and customer data meet the public internet. This guide sets out the server hardening for crypto exchanges wallet providers should treat as baseline in 2026, written for CTOs and security leads who need criteria they can test, not slogans. It covers SSH and bastion access, secrets and key handling, network segmentation, WAF and DDoS posture, logging and audit trail, and least privilege.
Nothing here guarantees an outcome, and every platform differs. Use it as a review framework and ask any provider for an itemised quote against your own architecture. If you want an outside team to carry out the work, our server hardening service page explains how we scope it.
Why crypto platforms need a stricter baseline
A conventional business can often recover from a compromised server by restoring a backup. A crypto platform usually cannot, because a transfer on a public ledger is final. That changes the priorities for hardening.
- Irreversibility: a stolen withdrawal cannot be recalled, so prevention and detection matter more than recovery.
- Direct financial targeting: attackers go after hot wallet services, admin panels, deployment pipelines and the staff who control them.
- Always-on exposure: trading and deposits run around the clock, so maintenance windows are short and patching must be planned carefully.
- Third-party dependency: node providers, custodians, KYC vendors and cloud accounts all widen the attack surface.
- Scrutiny from partners and regulators: banks, auditors and licensing bodies increasingly ask for evidence of controls, not only policies.
SSH and bastion access
Direct SSH from the internet to production servers is the first thing to remove. A hardened design routes all administrative access through a small number of controlled entry points.
- Place production hosts in private networks with no public SSH listener, and reach them only through a bastion or an identity-aware access proxy.
- Disable password authentication and root login entirely. Require key-based or certificate-based login, ideally with short-lived certificates issued after multi-factor authentication.
- Tie every session to a named person, never a shared account, so an action can always be traced to an individual.
- Record sessions on the bastion so commands run on signing or database hosts can be reviewed later.
- Restrict which source networks may reach the bastion, and remove access promptly when someone changes role or leaves.
Hardware-backed keys for engineers add real protection, because a stolen laptop alone no longer yields production access.
Secrets and key handling
This is the area where crypto platforms differ most from ordinary web businesses. Two categories of secret need different treatment: operational secrets such as database passwords and API tokens, and signing keys that control funds.
Operational secrets
Keep credentials out of source repositories, container images and shell history. Use a managed secrets store, inject values at runtime, rotate them on a schedule and rotate immediately after any suspected exposure. Give each service its own credentials, so one leak does not unlock everything.
Signing keys
Private keys that authorise transfers should not live on general-purpose application servers. Common patterns include hardware security modules, multi-party computation or multisignature schemes, and offline or air-gapped cold storage for the bulk of reserves. The hot wallet should hold only the balance needed for near-term withdrawals, with automated limits and an approval step for anything larger. Server hardening supports this by isolating the signing service, restricting what can talk to it and logging every request it receives. Hardening does not replace a sound custody design; it protects the machines around it. Our server hardening team reviews these boundaries as part of the engagement.
Network segmentation
Flat networks turn one compromised web server into a compromised company. Segmentation limits how far an intruder can move.
- Separate zones for public-facing services, application logic, databases, signing and wallet services, and administrative tooling.
- Default deny: firewall rules and security groups should block everything except flows that are documented and needed.
- No inbound path to signing hosts from the internet, and tightly limited internal paths from the application tier.
- Egress control: restrict outbound connections so a compromised host cannot freely call out to an attacker or download tools. Allow-list the node providers and APIs you actually use.
- Separate environments: staging and development must not share credentials, networks or data with production.
WAF and DDoS posture
Exchanges attract denial-of-service attacks, sometimes as a distraction while something else happens. Plan for volumetric floods as well as application-layer abuse against login, order and withdrawal endpoints.
- Put a reputable DDoS mitigation and CDN layer in front of public endpoints, and keep origin server addresses private so attackers cannot bypass it.
- Use a web application firewall tuned to your real traffic, with rules for authentication, API abuse and common injection patterns. Start in monitoring mode, then enforce.
- Apply per-account and per-address rate limits on sensitive actions such as login, password reset and withdrawal requests.
- Decide in advance how the platform behaves under attack: which features degrade first, and who can authorise emergency changes.
- Rehearse the runbook. A plan nobody has practised tends to fail under pressure.
Logging and audit trail
If a withdrawal looks wrong, you need to reconstruct exactly what happened. That requires logs that attackers cannot quietly edit.
- Ship logs off the host in near real time to a separate, access-restricted logging account, so compromising a server does not let someone erase their tracks.
- Capture authentication events, privilege escalation, configuration changes, firewall changes, API key creation and every request to the signing service.
- Synchronise clocks across systems so timelines can be rebuilt reliably.
- Make logs tamper-evident through write-once storage or hash chaining, and define retention periods that match your compliance obligations.
- Alert on high-risk events, such as a new administrator, a changed withdrawal limit or a login from an unusual place, and name who responds.
Least privilege
Least privilege is simple to state and difficult to maintain. Every person, service and automated job should hold only the access it needs for the task, and no more.
- Use role-based access with separate roles for developers, operations, support and finance. Avoid permanent administrator rights; grant elevated access on request, time-boxed and logged.
- Require two people for high-impact changes, such as altering withdrawal limits, changing allow-lists or deploying to the signing tier.
- Run services as unprivileged users, drop unneeded capabilities, and use read-only filesystems where the workload permits.
- Review access on a regular cycle and remove dormant accounts and unused API keys.
- Protect the CI/CD pipeline as carefully as production, since a compromised build system can ship malicious code with legitimate credentials.
Operating system and host baseline
Beneath the access and network controls sits the machine itself. Start from a recognised benchmark, such as the CIS benchmarks for your operating system, and document every deviation. Remove unused packages and services, enable mandatory access control where available, keep the kernel and libraries patched, and use immutable or rebuilt-from-image servers so drift is visible. Add file integrity monitoring and endpoint detection on critical hosts so unexpected changes raise an alert.
Criteria table for reviewing your current posture
Use this table to rate each area honestly. It is deliberately qualitative; the right target depends on your architecture and risk appetite.
| Area | Weak posture | Acceptable posture | Strong posture |
|---|---|---|---|
| SSH and admin access | Public SSH, shared accounts, password logins | Bastion with key-based login and MFA | Short-lived certificates, hardware keys, recorded sessions |
| Secrets handling | Credentials in repos or environment files | Central secrets store with rotation | Per-service secrets, automatic rotation, exposure alerts |
| Signing keys | Keys on application servers | Isolated signing service with limits | HSM, MPC or multisig, cold storage for reserves, dual approval |
| Network segmentation | Flat network | Separate zones with firewall rules | Default deny, egress allow-lists, isolated environments |
| WAF and DDoS | Origin exposed, no rate limits | CDN and WAF in front of public endpoints | Tuned rules, hidden origin, rehearsed attack runbook |
| Logging and audit | Local logs only | Central logs with basic alerts | Tamper-evident remote logs, tested alerting, named responders |
| Least privilege | Broad standing admin rights | Role-based access with periodic review | Time-boxed elevation, two-person approval on critical changes |
| Host baseline | Default installs, irregular patching | Benchmark-based builds, scheduled patching | Immutable images, integrity monitoring, tracked exceptions |
Most platforms find they are strong in some rows and weak in others. The weakest row on the path to the signing service is usually the one to fix first.
What drives the cost of a hardening project
We do not publish figures in an article, because they depend on your environment. These are the factors that move the price.
- The number of servers, cloud accounts and environments in scope.
- How much current infrastructure must be re-architected rather than reconfigured, for example introducing a bastion or splitting a flat network.
- Whether a custody redesign is included or only the hosting layer around it.
- The depth of logging, monitoring and alerting you want delivered.
- Evidence requirements from auditors, banking partners or regulators.
- Ongoing patching and review after the initial work, which is a recurring rather than a one-off item.
Ask for an itemised quote so each of these appears as a visible line instead of a single lump sum.
A sensible order of work
You rarely harden everything at once on a live exchange. A staged plan keeps risk and downtime manageable.
- Inventory servers, accounts, keys and access paths, and identify the route to the signing service.
- Close the most exposed doors first: public SSH, shared credentials and exposed origins.
- Introduce segmentation and egress controls in monitoring mode, then enforce.
- Centralise logs and alerts before making large changes, so you can see their effect.
- Apply host baselines and patch cycles to the least critical systems first, then the sensitive ones.
- Test with a tabletop exercise and an independent review before declaring the work complete.
If you want help sequencing this around your release calendar, our server hardening services engagement starts with a scoping review.
Why Companies Choose CloudHouse for Server Hardening
Teams come to CloudHouse because we plan delivery in clear stages, stay available for support after the work is live and provide transparent, itemised quotes so you can see what each control costs. We aim to explain our changes in plain language, so your own engineers understand what was done and why.
Conclusion
Hardening a crypto platform is about shrinking what an attacker can reach and making sure any attempt is visible. Control administrative access, keep signing keys isolated, segment the network, prepare for DDoS and abuse, keep tamper-evident logs and apply least privilege everywhere. Score yourself against the table, fix the weakest link first, and revisit it regularly. To discuss your environment and receive an itemised proposal, visit our server hardening page and request a quote.
