Skip to main content



One of the fundamental architectural choices of the Bitfount platform, different from many other federated architectures, is that Bitfount follows a messaging architecture. This means that services that connect to Bitfount only make outgoing HTTP connections and can happily sit behind a firewall.

Communication protocols

  • All data entering or leaving Pods, modelling services or Bitfount infrastructure uses TLS/HTTPS
  • All communication and training-orchestration messages are end-to-end encrypted. This removes any requirement to trust Bitfount with respect to the raw Pod data or analysis outcomes.

Your data (accessed via Bitfount Pods)

Running a Bitfount Pod can be hosted directly by the data provider, either locally (i.e. on-premise) or within their cloud infrastructure e.g. Amazon AWS, Google Cloud Platform, Azure. This data never leaves the Pod. The data stored within a Pod never moves from its location and is not accessible to Bitfount or any other parties unless access is specifically granted.

The only Pod information shared with Bitfount is metadata. More information on the metadata Bitfount has access to can be found in our privacy policy.

Securing your network

When running a Pod, there are several controls we recommend you put in place to ensure that outside users can’t break into your network:

  1. By default, all code that runs is pre-installed with your Pod and can only be called through configuration options. This can be overridden if you want to use custom models, but this option should only be enabled for highly trusted users (e.g. employees of your organisation).
  2. Pods should be run within a docker container with limited access to the rest of your network. You should only allow these docker containers access to the specific data that you want to make available.
  3. We recommend that any data that you make available is a copy of source data.
  4. Any connections to databases should be set to be read-only.
  5. Pods can be set to refuse specific jobs or require privacy settings regardless of what has been set in the access manager. This can enforce additional certainty that specific operations can never happen.

Bitfount’s own security

As you might imagine, Bitfount takes security very seriously. Security is a core part of what our product aims to help with! The following are some of the things we are doing to make sure our own code and infrastructure are secure:

  • Automated security tests on all our code
  • Regular penetration tests on all our services
  • Monitoring tools to try to catch intrusions and incidents
  • Segregated production environment with limited human access
  • Various process-level security policies, including a secure development policy.
  • ISO 27001 certification.
  • Access to the Hub and Access Managers is protected by strong authentication and authorization controls, with user passwords not being held by Bitfount.
  • Bitfount’s authentication (Auth0) and infrastructure (AWS) providers hold industry-leading security certifications such as SOC 2 Type II, ISO 27018 and ISO 27001.