In the Web3 world, our project’s most valuable assets, such as tokens, governance powers, and user trust, often hinge on a single point of failure: the private key.
Private keys are the cryptographic backbone of your blockchain infrastructure. They prove the ownership of a wallet address and control over assets through signing transactions with the private keys, for example, transferring tokens, authorizing smart contract upgrades, signing cross-chain transactions, and controlling treasury wallets.
Yet despite their critical role, private keys are often mismanaged, left in plaintext, stored in unsecured environments, encrypted insecurely, derived from low entropy, or controlled by a single individual. This makes them prime targets for attackers and a leading cause of catastrophic breaches across the industry.
As a project manager, you may not interact with private keys directly, but the consequences of a compromised key fall squarely on your shoulders, from operational disruptions to financial loss and reputational damage. Understanding the risks and ensuring proper key management practices are in place is not just a technical concern. It’s a business imperative.
While we've already introduced the concept of private keys and the risks of centralization in two of our previous blogs, this post takes it a step further. We'll dive deeper into the security considerations around private key generation, storage, usage, and why getting each of these stages right is critical to protecting your Web3 projects. Let's start with how a private key can be generated.
Private key generation is the foundational step in any blockchain system, and it's one of the most overlooked yet critical components of overall security. Broadly, key generation can be performed through software-based methods or by using dedicated Hardware Security Modules (HSMs).
Securely generating a private key relies on several pivotal factors:
Most software-based key generators rely on Pseudorandom Number Generators (PRNGs). While convenient, PRNGs are vulnerable if improperly seeded or implemented, and often lack sufficient entropy, particularly in constrained or misconfigured environments. For attackers with enough resources or insider knowledge, these flaws can be exploited to predict or reconstruct private keys. One notable example is the vulnerability in Profanity of 2022. Profanity is a vanity-address generator that uses a 32-bit seed and expands it into a 256-bit private key. Because there are only 2^32 possible initial key pairs and each iteration is reversible, attackers could recover any Profanity-generated private key from its corresponding public key. In September 2022, this flaw was exploited against multiple users, most strikingly Wintermute, which suffered a $160 million loss. For more information about the exploit, please check our previous article here.
This is why the gold standard for key generation relies on specialized hardware. A Hardware Security Module (HSM), a tamper-resistant appliance, is purpose-built for this task. Certified HSMs (e.g., FIPS 140-3) provide verifiable assurance through features like:
The process of using this hardware is often formalized in a Key Generation Ceremony, a scripted and audited procedure where multiple trusted individuals convene to create the organization's root keys within the secure boundary of the HSM. This eliminates single points of failure from the very inception of the keys.
For teams without access to on-premise HSMs, leading cloud providers (such as AWS CloudHSM, GCP Cloud HSM, and Azure Managed HSM) offer HSM-backed services. These platforms provide scalable, compliant, and secure environments for key management, with API access and integration into modern DevOps workflows.
Once a private key is securely generated, it must be stored in a highly controlled and tamper-resistant environment. The core principle of secure storage is isolation. The key material should never be exposed in plaintext to any human, operating system, or application outside a trusted execution boundary.
Centralization Risks in Key Management
Many dApps claim decentralization but rely on centralized servers to store or manage users' private keys, creating a single point of failure. If the backend is compromised, all user assets become vulnerable. During a penetration test, we found that some bridge apps use a centralized backend to handle the private key for contract withdrawals. If this key isn’t securely stored, attackers can execute unauthorized withdrawals and drain funds. We also saw wallets poorly designed to send encrypted private keys to the backend with weak encryption. A compromised backend puts users at risk. Additionally, some companies even skip proper network penetration tests, allowing attackers to move laterally within their network to access backend private keys. This vulnerability remains one of the most critical issues we encounter.
Weak Encryption Practices and Lack of Transparency
Encryption is a major vulnerability for many applications. While some claim to use strong standards like AES-GCM or 256-bit encryption, we have also seen some bots promote themselves as using highly secure double encryption, which in reality offers little actual protection. This raises doubts about developers’ understanding of secure key storage and adherence to best practices. Besides, we have also seen weak encryption choices like MD5 hashing and ECB mode for private keys. Despite this being well-known weak encryption, developers still use these insecure methods.
Insecure Storage Practices
Storing sensitive data like access tokens, encryption keys, or mnemonics in unsecured places such as local storage or unencrypted app preferences makes them easily accessible to attackers with physical or remote access to a user’s device. If the device is rooted or jailbroken, this risk becomes even greater, as attackers can bypass many of the built-in security protections. Without encryption or proper sandboxing, attackers can steal these credentials to compromise the entire account.
To reduce risk and align with industry best practices, we recommend a layered and resilient storage architecture:
Isolated Local Storage on User Devices
To prevent exposure of private keys in logs, memory, or insecure environments, keys should be stored locally on user devices using secure storage like Apple’s Secure Enclave, Trusted Execution Environments (TEEs), or encrypted OS-level keychains. These isolate keys from the main app, protecting them even if the device is compromised. For devices lacking advanced hardware security, fallback to encrypted storage options such as Android’s Keystore, encrypted SharedPreferences, or iOS Keychain is recommended.
Hardware Security Modules (HSMs)
Software-based storage is inherently vulnerable. If the host system is compromised, an attacker can steal the encrypted key file to launch offline brute-force attacks or use keyloggers to capture the decryption password. An HSM solves this problem with its isolated design.
By using certified HSMs for storage, organizations maximize security versus software-only solutions and satisfy the stringent expectations of regulators and cyber-insurance underwriters.
Multi-Party Computation (MPC)
MPC splits private keys into encrypted shares stored across different locations, requiring multiple authenticators for recovery. This eliminates single points of failure and adds layers of security through multi-factor authentication (biometrics, KYC, secure links). Choosing well-audited MPC solutions that restrict private key export and enforce strong access controls is crucial for trust and asset protection.
Multi-Signature (Multisig) Wallets
Multisig wallets require multiple independent approvals for transactions, preventing unauthorized fund movements even if one key is compromised. By integrating multisig logic at the protocol or smart contract level, Web3 apps mitigate phishing, insider threats, and single-point failures.
Hardware Wallets for End-User Key Management
Hardware wallets keep private keys offline, enhancing security. Use multiple devices with distinct roles (e.g., separate wallets for daily use and multisig signing to isolate critical processes and reduce risk). Maintain backup hardware wallets securely to ensure recoverability from loss or damage. This structured approach balances convenience with robust asset protection.
Secure key generation and storage is only half the battle. Even with an HSM acting as your root of trust, the security of your digital assets ultimately depends on how private keys are used in practice. People, processes, and policy enforcement determine whether the system is resilient or dangerously exposed.
A secure key usage strategy includes well-defined operational procedures, clear access controls, and automated safeguards that minimize the chance of human error, insider abuse, or malware-based manipulation.
Even the strongest hardware can’t prevent poor decisions or procedural mistakes. A compromised operational process, such as a rushed withdrawal, an overlooked approval, or an unclear delegation of authority, can completely bypass the protections offered by HSMs or multisig setups.
This is why we recommend that every team conduct an Operational Integrity Assessment, which evaluates how the private keys are actually used in day-to-day operations. The goal is to surface weak links in transaction flows, access management, policy enforcement, and human factors.
Signing a transaction is the most sensitive moment in the life cycle of a private key. It’s when real value is placed at risk. The signing process must be designed to verify both authenticity and intent while protecting against compromise. Key best practices include:
Applying the principles above is essential, but they must be evaluated within the context of specific, high-risk operational areas. A thorough assessment focuses on the following domains.
Cold Storage Security and Management. It involves evaluating the physical security of the location where the hardware is stored, strict access control protocols for personnel, and documented procedures for the key generation ceremony. Furthermore, it assesses disaster recovery plans, ensuring that secure, encrypted backups of the keys exist and can be restored safely in a crisis.
Transfer Mechanisms between Storage Types. The process for moving funds between them is a critical control point. Assessments must scrutinize the security of the protocols used for refilling hot wallets from cold storage, ensuring these transfers are subject to the strictest M-of-N and policy controls to prevent unauthorized draining of the main reserve.
Deposit and Withdrawal Process Security. This assesses the end-to-end flow of funds into and out of the custody system. For deposits, it involves monitoring for suspicious patterns that could indicate money laundering or exploits. For withdrawals, it verifies that the entire security framework, from M-of-N approvals and policy checks to WYSIWYS validation, is rigorously and consistently applied to every single transaction, without exception.
CertiK delivers end-to-end security services that strengthen key management from generation and storage to day-to-day use. We have supported teams running public-facing dApps and large institutional custody platforms, and our work blends deep technical insight with clear, collaborative guidance.
Architecture Review and Threat Modeling
We analyze how a system’s parts interact, how trust is built between them, and where design assumptions create hidden risk. Key management is central to this review, covering how keys are generated, stored, isolated, and invoked during signing or approval flows. Threat modeling then maps realistic attack paths, showing where controls could fail under real-world pressure. Findings translate into practical design and process changes that fit the project’s scale and goals.
Penetration Testing
Our team simulates focused attacks against backend services, APIs, user interfaces, and supporting infrastructure to expose weaknesses in logic, access control, and configuration. Testing depth matches the access provided (black-box when little is known, white-box when full detail is shared) so results reflect plausible attacker capabilities. Each engagement ends with proof-backed issues and prioritized fixes that let engineering teams act quickly.
Operational Security Review
We examine how everyday workflows, devices, and people influence key safety. This includes access provisioning, device hygiene, communication practices, and incident-response readiness under stress. By linking technical safeguards to real operational habits, we uncover gaps that paperwork alone can miss and recommend changes that hold up over time.
Our engagements are designed to integrate security into the system’s lifecycle. Not just as a final step, but as a foundation for trustworthy development. Whether you're building a custody solution, managing user keys in production, or designing new wallet architecture, CertiK can help you assess risks, harden your system, and deploy with greater confidence.
Private key management isn’t just a backend detail. It’s the foundation of your project’s security and operational integrity. From generation to storage to day-to-day usage, each stage introduces risks that can be exploited if not properly addressed.
Whether you're securing a multi-chain bridge, managing a DAO treasury, or launching a new smart contract system, the cost of neglecting key management can be devastating. Fortunately, with the right strategy, tools, and security practices in place, these risks are manageable and preventable.
CertiK specializes in helping Web3 teams build resilient, secure systems that scale. From designing secure key ceremonies to auditing DevOps pipelines and implementing advanced key-sharing schemes like TSS or MPC, we partner with you to ensure your most critical assets remain secure at every stage.