Bitpanda Enterprise Custody is designed to protect private keys through a combination of secure custody architecture, controlled signing workflows, role-based access, and operational governance.
Private keys are not exposed to users through BE Custody Web or the Bitpanda Custody iOS app. Users interact with custody workflows through authorised interfaces and approval processes rather than directly handling private keys.
Why private key protection matters
Private keys control the ability to authorise blockchain transactions. For institutional custody, private key protection must be supported by technical, operational, and governance controls.
These controls help reduce risks such as:
- Unauthorised transaction signing
- Misuse of privileged access
- Operational error
- Inappropriate concentration of authority
- Loss or compromise of sensitive cryptographic material
- Weak separation between transaction creation and approval
Are private keys visible to users?
No. Private keys are not displayed to users in BE Custody Web or the Bitpanda Custody iOS app.
Users do not need to copy, export, or manually manage private keys as part of normal custody operations. Transaction and approval workflows are performed through controlled product interfaces and configured authorisation processes.
How are signing actions controlled?
Signing actions are governed by the organisation’s BE Custody configuration.
Depending on the setup, controls may include:
- Authorised user roles
- Transaction approval workflows
- Quorum approval requirements
- Wallet or policy-level controls
- Governance processes for sensitive changes
- Audit history and operational records
- Controlled access to transaction creation and approval functions
The exact controls available depend on the organisation’s custody model, permissions, and configuration.
Can one user move assets alone?
This depends on the organisation’s configuration.
BE Custody can support approval and quorum models that require more than one authorised user to review or approve sensitive actions. Organisations should configure roles, permissions, and approval workflows in line with their internal governance model and risk appetite.
Users should not approve transactions or governance requests unless they recognise the request and have reviewed the details.
What should users protect?
Although private keys are not exposed through normal user workflows, users are still responsible for protecting their own access and approval credentials.
Users should protect:
- Their BE Custody login details
- Their email account used for access
- Their approved device
- Their Bitpanda Custody iOS app access
- Their PIN, biometric authentication, or other local authentication methods
- Any API credentials assigned to their organisation or integration
Do not share passwords, PINs, authentication information, API keys, API secrets, private keys, or seed phrases.
What should organisations review?
Organisations should regularly review:
- Which users have access to BE Custody
- Which roles and permissions are assigned
- Whether approval workflows remain appropriate
- Whether quorum requirements align with internal governance
- Whether former users have been removed
- Whether access to API credentials is controlled
- Whether security or operational incidents require access changes
Access and approval rights should follow the principle of least privilege.
Why are some security details not published?
Some implementation details are not published in the Help Centre because they could reduce the effectiveness of security controls if disclosed publicly.
Bitpanda Enterprise Custody can provide appropriate security, operational, and due diligence information through approved commercial, legal, security, or compliance review channels where required.
What should I do if I suspect a security issue?
If you suspect unauthorised activity, credential compromise, unexpected approvals, or unusual transaction behaviour, do not approve any further requests.
Follow your organisation’s security escalation process and contact Bitpanda Enterprise Custody Support through the approved support channel.
Do not include passwords, PINs, private keys, seed phrases, API keys, API secrets, or other sensitive authentication information in a support request.