API keys, API secrets, access tokens, instruction keys, and related credentials should be treated as sensitive authentication material.
In BE Custody integrations, API credentials may allow authorised systems or services to access custody-related workflows or information. They should be created, stored, used, rotated, and retired according to your organisation’s security and governance process.
Client responsibility for third-party systems
Your organisation is responsible for the security, configuration, operation, and monitoring of any third-party systems used to store, manage, transmit, or process API credentials.
This includes, but is not limited to:
- Third-party key management systems
- Secrets managers
- Cloud infrastructure
- CI/CD tooling
- Internal applications
- Logging and monitoring platforms
- Middleware or integration services
- Developer workstations or operational tooling
- Third-party APIs, exchanges, or service providers
Bitpanda Enterprise Custody is not responsible for the security, availability, configuration, compromise, misuse, or operational behaviour of third-party systems or client-managed infrastructure.
If API credentials, instruction keys, access tokens, or related secrets are stored, exposed, misconfigured, transmitted, logged, or used through systems managed by your organisation or its service providers, responsibility for managing that risk lies with your organisation.
Why API key protection matters
API credentials can provide access to custody-related functions or operational data, depending on the permissions and configuration.
Poorly protected credentials may increase risks such as:
- Unauthorised access to custody information
- Unauthorised or unexpected API activity
- Data exposure
- Operational disruption
- Integration misuse
- Difficulty attributing actions to authorised systems or teams
- Unintended instructions being submitted through an approved integration
API credentials should be protected with the same level of care as other privileged access mechanisms.
Who should manage API credentials?
API credentials should only be managed by authorised users, teams, or systems.
Depending on your organisation’s operating model, responsibility may sit with:
- Engineering
- Platform operations
- Security
- Treasury operations
- Compliance operations
- Internal tooling teams
- Authorised administrators
Ownership, approval, storage, rotation, monitoring, and incident response responsibilities should be clearly defined.
How should API keys be stored?
API credentials should be stored only in approved secure systems controlled or approved by your organisation.
Organisations should avoid storing API credentials in:
- Source code repositories
- Shared documents
- Tickets or comments
- Chat messages
- Email threads
- Local files on unmanaged devices
- Logs or error traces
- Screenshots
- Client-side applications or browser code
Use your organisation’s approved secrets management or key management process for storage and access control.
How should third-party KMS or secrets management be governed?
If your organisation uses a third-party KMS, secrets manager, or cloud-based credential storage service, your organisation is responsible for ensuring that it is appropriately configured and governed.
This may include reviewing:
- Access permissions
- Administrator privileges
- Encryption settings
- Rotation policies
- Backup and recovery processes
- Audit logging
- Monitoring and alerting
- Network access controls
- Change management
- Vendor and service provider risk
- Incident response procedures
Your organisation should ensure that only authorised users, systems, or services can access API credentials.
How should permissions be assigned?
API access should follow the principle of least privilege.
This means API credentials should only have the permissions required for the approved integration or workflow. Organisations should avoid using broad permissions where narrower access is sufficient.
Access should be reviewed when systems, workflows, users, integrations, or operational requirements change.
How often should API keys be rotated?
API key rotation should follow your organisation’s internal security policy.
Organisations may rotate credentials:
- On a regular schedule
- When a user, system, or integration no longer requires access
- After suspected or confirmed exposure
- After changes to integration ownership
- After changes to infrastructure or deployment processes
- When required by internal audit or security policy
Rotation should be coordinated to avoid unnecessary disruption to production custody workflows.
What should developers consider?
Developers and integration teams should consider:
- Secure secrets storage
- Environment separation
- Least-privilege permissions
- Monitoring and alerting
- Secure logging
- Key rotation procedures
- Access review processes
- Incident escalation paths
- Change management before production use
- Removal of unused credentials
- Security and governance of any third-party KMS or secrets management tooling
API credentials should not be exposed in public repositories, shared support materials, screenshots, logs, browser code, or client-side applications.
What should I do if an API key may have been exposed?
If an API key, API secret, access token, instruction key, or related credential may have been exposed, treat it as a security incident.
Follow your organisation’s internal security escalation process immediately. This may include revoking or rotating the credential, reviewing recent activity, checking affected systems, and confirming whether any unauthorised activity occurred.
If the exposure involves a third-party KMS, secrets manager, cloud provider, internal system, or service provider managed by your organisation, your organisation is responsible for investigating and remediating that environment.
Contact Bitpanda Enterprise Custody Support through the approved support channel if support is required.
Do not include exposed credentials, keys, secrets, passwords, PINs, private keys, seed phrases, or access tokens in a support request.