At Benchling, securing customer data isn't just a priority, it’s foundational to our mission of advancing biotechnology research. From robust encryption practices to thoughtfully integrated AI features, Benchling's infrastructure and operations are built on a security-first mindset. This article combines key policies, controls, and best practices to provide a single view of our security ecosystem.
To explore Benchling’s trust and compliance practices in full detail, visit: https://securitytrust.benchling.com
Security Program Foundations
At Benchling, trust is in our DNA. We recognize that we have a big responsibility ensuring your data is both protected and secured, and we consider this a core commitment to our customers.
Security
All data in Benchling is encrypted at rest and served over HTTPS. Backend services are firewalled off from the Internet; only web servers are accessible to afford network isolation.
Importantly, all data belongs to the user. We take no ownership over intellectual property. Hundreds of thousands of scientists in both academia and industry use Benchling to develop core IP.
Benchling is designed with high availability in mind and data is stored with high redundancy. Our AWS-hosted databases are synchronously replicated across datacenters and files are stored in Amazon S3, which stores files across multiple datacenters and is designed for 99.999999999% durability (11 9s). All data is stored encrypted at rest.
As an additional measure, Benchling performs several layers of backups to ensure data recovery if necessary. Database changelogs are captured along with daily snapshots to allow Benchling engineers to perform point-in-time recovery for any time in the last 35 days. Weekly snapshots are also captured and stored cross region in the event of large scale disasters.
Access to customer data is strictly controlled and audited. Your data is stored on production networks separate from Benchling employees, and access to customer data requires administrative approval and is granted only on an as-needed, temporary basis.
Our security program is rooted in:
- Industry standards backing: Our program aligns with the NIST cybersecurity framework and the ISO standard for information security, ensuring holistic investments in security.
- External audits: Our commitment to transparency means that our program undergoes external audits annually, encompassing compliance-based audits (ISO 27001, SOC 2 Type 2), customer audits, and technical system audits.
Incorporating security in product development
Security is also integrated throughout our software development life cycle. We employ:
- Secure coding guidelines and annual mandatory secure coding training
- Threat modeling and architecture reviews
- Automated and manual security checks
- Regular vulnerability scanning, including third-party penetration testing
Maintenance and vulnerability management
Beyond deployment, we invest in regular maintenance. Our vulnerability management tools scan our systems, encompassing our production infrastructure, source code, and corporate assets, at least weekly.
Corporate security practices
Aligned with ISO 27001 standards, our corporate security practices ensure:
- Strict access controls through our single sign-on ("SSO") provider with mandatory multi-factor authentication for IT services
- Comprehensive onboarding and offboarding processes
- Mandatory annual security awareness training for all Benchling personnel
Certification
Benchling’s security and privacy programs are certified under ISO/IEC 27001:2013 and the Data Privacy Framework, as approved by the Department of Commerce. Benchling also maintains a SOC 2 Type 2 Attestation.
Security documentation
To learn more about Benchling’s security practices, please read our Information Security Policy and our Security Whitepaper.
Privacy and data protection compliance
Benchling is compliant with all applicable data protection laws and regulations, including both the General Data Protection Regulation ("GDPR") and the California Consumer Privacy Act, as amended by the California Privacy Rights Act (CCPA/CPRA). To learn more about Benchling’s privacy practices, please visit our Privacy Page.
Further protect your Benchling tenant
To take more steps to protect your organization’s data and further ensure only those who need access to your data have it, we recommend following these best practices.
Most of the options require administrator permissions to take action. If you do not have administrator permissions, coordinate with your Benchling administrators to make these changes.
Manage user access
One of the most effective ways to ensure the security of your data is to give access only to those who require it. You can configure access and permissions based on application or project, and can customize registry permissions depending on your organization’s needs.
External collaborators
By default, only users with your organization’s domain email can access your Benchling tenant. If you need to work with external collaborators, contact your Benchling representative to get access for their email address or domain. You can then apply permissions to control what data your collaborator can access.
Configure custom access policies
Customize your access policies to create tailored permissions for your organization beyond Benchling’s standard read, write, and admin permissions. To learn more about designing access policies, see the linked article.
Note: Before configuring access policies, they must be enabled on your tenant. To get access policies enabled, contact your Benchling representative, email support@benchling.com, or message us using our in-app chat.
Integrate Benchling with your Identity Provider
Benchling supports Security Association Markup Language (SAML), and can integrate with a wide range of Identity Provider (IdP) solutions to support single-sign on (SSO). Configuring SAML SSO to fit Benchling seamlessly into your security ecosystem will help ensure only the appropriate people have access to your data.
To learn more about configuring SAML SSO, see the linked article.
Set IP address range restrictions
Benchling can establish IP allow lists to restrict traffic outside a defined range of IP addresses. If enabled, all IP addresses outside of the defined range are blocked from accessing your Benchling tenant.
If your organization is considering IP address range restrictions, contact your Benchling representative.
Set idle and session timeouts
There are often security or compliance reasons to enforce users be active when viewing data in Benchling, or re-authenticate regularly. You can control timeout length on your tenant with:
- Idle timeouts control how long a user can be idle before they’re automatically logged out of Benchling. They help secure your work environment by minimizing opportunities for data to be exposed without supervision and are particularly useful where shared workstations are common.
- Session length timeouts control the maximum time a user can be logged into Benchling before they’re forced to re-authenticate. They ensure anyone using Benchling has current credentials, especially when using your own identity provider to authenticate users.
It’s common to use both settings.
Timeout recommendations
We recommend starting with the following settings:
- Idle timeout: 720 minutes (12 hours)
- Session length timeout: 144 hours (6 days)
These values are set to balance security while minimizing disruption to user experience, and are what we set by default for new tenants. Sessions requirements will vary based on your organization’s needs, so you may need to adjust these limits later. Users on the Academic tenant will also be subject to these limits, but do not have the option to change them.
Session requirements will vary based on your organization’s needs, so you may need to adjust these limits later.
You can’t set timeouts for periods of time below these minimums:
- Idle timeout: 5 minutes, set in minute increments
- Session length timeout: 12 hours, set in hour increments
Note: When determining timeout limits, we recommend setting the session length timeout longer than idle timeout. Not doing so is equivalent to having idle timeout disabled.
Considerations for authenticating using your own identity provider
If you're using your own identity provider to authenticate, like SAML authentication, ensure the identity provider app session length is configured at or below the Benchling idle timeout. If not, the existing browser session might allow the user to log in without re-entering their credentials.
Below are instructions to configure session length for some of our most common identity providers:
Timeout user experience
The table below describes the user experience for each timeout limit while the user is within and approaching the end of a session.
| Idle timeouts | Session length timeouts | |
| User is within the timeout limit |
Sessions won’t expire while a user is active.
As a user interacts with Benchling, it automatically extends the session. Activity is determined by mouse movement, keyboard input, and other page interactions. |
Users often re-authenticate automatically by closing and re-opening the browser where they’re using Benchling. |
| User is approaching the timeout limit |
When a user approaches the idle timeout limit, a pop-up message displays informing them their session is about to end and they’ll be logged out. To extend the session, they can click Continue.
If they’re logged out, the site redirects to a Session Expired page where they can log back in. |
When a user reaches the end of their session, the page dims and a message explains their session has expired.
When dimmed, the page’s content is still visible, but users can’t interact with it. They need to re-authenticate before interacting with it again. |
Manage timeout limits
You can manage both timeout limits in the Tenant Admin Console:
- Click your initials in the bottom-left corner, then select Tenant Admin Console.
- Click Settings, then click Configurations.
Networking Configuration and Security
IT and Security teams should be aware of the following information to allow access to, and secure networking connections with, Benchling.
Resources accessed by the Benchling application
Note: in the instructions below, please substitute `${tenant-domain}` using your specific tenant's URL. If you have multiple tenants, you will need to repeat the configurations for every tenant.
In order to use the Benchling web application, your clients must be able to resolve the following URLs:
| URL | Purpose | Benchling Owner |
| ${tenant-domain}.benchling.com | The Benchling web app | @monolith-infra-team |
| ${tenant-domain}.bnchcdn.com | Static resources for the Benchling web app | @monolith-infra-team |
| postgres-warehouse.${tenant-domain}.benchling.com |
Warehouse direct access. Only required only if the customer is using Benchling's Warehouse product.
Note: See below for Validated Cloud customers whose Warehouses were created after March 2024. |
@big-data-infra-team |
| postgres-warehouse.${tenant-domain}.vc-postgres-warehouse.benchling.com | Warehouse direct access for Validated Cloud customers whose Warehouses were created after March 2024. Only required only if the customer is using Benchling's Warehouse product. | @big-data-infra-team |
| benchling-*.s3.amazonaws.com | Customer files stored in Benchling | @monolith-infra-team |
| cloud.typography.com | Enables font rendering | @dev-productivity-team |
| fonts.googleapis.com | Enables font rendering | @dev-productivity-team |
| app.getsentry.com | Debugging client-side issues | @performance-eng-team |
| rum.browser-intake-datadoghq.com | Monitoring client-side metrics | @performance-eng-team |
| session-replay.browser-intake-datadoghq.com | Debugging client-side issues | @performance-eng-team |
| benchlinghelp.zendesk.com | Enables support functions | @team-app-core |
| assets.zendesk.com | Enables support functions | @team-app-core |
| *.aptrinsic.com | Enables support functions | @team-app-core |
| *.smooch.io | Enables support functions | @team-app-core |
Ports on which Benchling is accessed
- The Benchling web application is reachable on port `443`
- The Warehouse is reachable on port `5432`
Securing connections originating from clients to Benchling
Benchling supports individually configurable IP allowlists on both the Benchling web application and the Warehouse. The allowlists enable you to restrict inbound traffic to Benchling to specific CIDR ranges. Please reach out to your customer support contact to configure these IP allowlists.
Securing connections originating from Benchling to customers
For some use cases (specifically, some Printer setups and Webhooks), Benchling may originate connections from stable IP addresses to your machines. The IP addresses vary depending on the region and product version (Standard Benchling vs. Validated Cloud) that you are using.
The following table contains the list of IP addresses from which connections may originate:
| Benchling hosting region | Product version | IP addresses from which connections may originate |
| US East | Standard Benchling |
|
| US East | Validated Cloud |
|
| US West | Standard Benchling |
|
| EU Central | Standard Benchling |
|
| EU Central | Validated Cloud |
|
AI security and governance
For more about Data protection and security for AI at Benchling, see the linked article.