Access

2025.10

Access to Bioscope AI systems and applications is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, consultants, and any other entity, is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization’s information systems. These safeguards have been established to address the HIPAA Security regulations and industry best practices.

Policy Statements

Access Control Policy

Bioscope AI policy requires that:

(a) Access to all computing resources, including servers, end-user computing devices, network equipment, services and applications, must be protected by strong authentication, authorization, and auditing.

(b) Interactive user access must be associated to an account or login unique to each user.

(c) All credentials, including user passwords, service accounts, and access keys, must meet the length, complexity, age, and rotation requirements defined in Bioscope AI security standards.

(d) Use strong password and multi-factor authentication (MFA) whenever possible to authenticate to all computing resources (including both devices and applications).

(e) MFA is required to access any critical system or resource, including but not limited to resources in Bioscope AI production environments.

(f) Unused accounts, passwords, access keys must be removed within 30 days of last use.

(g) A unique access key or service account must be used for different application or user access.

(h) Authenticated sessions must time out after a defined period of inactivity.

Access Authorization and Termination

Bioscope AI policy requires that:

(a) Access authorization shall be implemented using role-based access control (RBAC) or similar mechanism.

(b) Standard access based on a user’s job role may be pre-provisioned during employee onboarding. All subsequent access requests to computing resources must be approved by the requester’s manager, prior to granting and provisioning of access.

(c) Access to critical resources, such as production environments, must be approved by the security team in addition to the requester’s manager.

(d) Access must be reviewed on a regular basis and revoked if no longer needed.

(e) Upon termination of employment, all system access must be revoked and user accounts terminated within 24 hours or one business day, whichever is shorter.

(f) All system access must be reviewed at least annually and whenever a user’s job role changes.

Shared Secrets Management

Bioscope AI policy requires that:

(a) Use of shared credentials/secrets must be minimized and approved on an exception basis.

(b) If required by business operations, secrets/credentials must be shared securely and stored in encrypted vaults that meet the Bioscope AI data encryption standards.

(c) Usage of a shared secret to access a critical system or resource must be supported by a complimenting solution to uniquely identify the user.

Privileged Access Management

Bioscope AI policy requires that:

(a) Users must not log in directly to systems as a privileged user.

• A privileged user is someone who has administrative access to critical systems, such as a Active Directory Domain Administrator, root user to a Linux/Unix system, and Administrator or Root User to an AWS account.

(b) Privileged access must only be gained through a proxy, or equivalent, that supports strong authentication (such as MFA) using a unique individual account with full auditing of user activities.

(c) Direct administrative access to production systems must be kept to an absolute minimum.

(d) Members of the Security team must review direct administrative and/or privileged access to production systems every 60 days to ensure access patterns are kept to a minimum.

Controls and Procedures

Standards for Access Provisioning

Workforce Clearance

1. The level of security assigned to a user within the organization’s information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user’s job classification and/or to a user needing access to carry out treatment, payment, or healthcare operations.
2. All access requests are treated on a “least-privilege” principle.
3. Bioscope AI maintains a minimum necessary approach to access to Customer data. As such, Bioscope AI, including all workforce members, does not readily have access to any ePHI.

Access Authorization

1. Role-based access categories for each Bioscope AI system and application are pre-approved by the Security Officer.
2. Bioscope AI utilizes hardware-defined and/or software-defined boundaries to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.

Person or Entity Authentication

1. Each workforce member has and uses a unique user ID and password that identifies him/her as the user of the information system.
2. Each Customer and Partner has and uses a unique user ID and password or OpenID Connect that identifies him/her as the user of the information system. This is enforced through the use of Auth0.
3. All customer support interactions must be verified before Bioscope AI support personnel will satisfy any request having information security implications.

Unique User Identification

1. Access to the Bioscope AI Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
2. Password requirements mandate strong password controls (see below).
3. Passwords are not displayed at any time and are not transmitted or stored in plain text.
4. Default accounts on all production systems and environments, including root, are disabled/locked.
5. Shared accounts are not allowed within Bioscope AI systems or networks.

Automatic Logon and Logoff

1. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with Bioscope AI workstations or production systems.

2. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password-protected screen saver or logging off the system).

3. Information systems automatically lock users such as enabling password-protected screen saver after 2 minutes or less of inactivity.

4. Information systems automatically enter standby or log users off the systems after 30 minutes or less of inactivity.

5. The Security Officer must pre-approve any exception to automatic log off requirements.

Password Management

Bioscope AI follows password management best practices aligned with NIST SP 800-63B guidelines, focusing on password strength through length and complexity rather than arbitrary rotation requirements.

1. User IDs and passwords are used to control access to Bioscope AI systems and may not be disclosed to anyone for any reason.

2. Users may not allow anyone, for any reason, to have access to any information system using another user’s unique user ID and password.

3. On all production systems and applications in the Bioscope AI environment, password configurations are set to require:

   • Minimum length of 15 characters (12 characters acceptable when MFA is enforced);
   • Support for passphrases (spaces and special characters allowed);
   • No periodic password expiration unless compromise is suspected or detected - forced periodic rotation leads to predictable, weaker passwords;
   • Passwords should focus on entropy and length rather than requiring specific character composition rules;
   • Prevention of password reuse using a history of the last 24 passwords;
   • Account lockout after 5 invalid attempts with appropriate timeout periods.

   Exceptions:

   • Administrative and privileged accounts may be required to rotate passwords if not protected by phishing-resistant MFA.
   • Password expiration may be enforced for compliance requirements specific to certain systems or contracts.

4. All system and application passwords must be stored and transmitted securely.

   • Passwords are stored in a hashed format using Argon2id, bcrypt, scrypt, or PBKDF2 with appropriate work factors according to NIST SP 800-63B standards.
   • Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in Data Protection.
   • Transmitted passwords must be encrypted in flight pursuant to the requirements in Data Protection.

5. Breached Password Protection: Passwords may not be found in known breached password databases or be commonly-used, expected, or compromised passwords.

   • Bioscope AI leverages automated screening against known compromised password databases (e.g., Have I Been Pwned API or equivalent) during password creation and reset.
   • This screening is updated continuously and integrated into authentication systems.
   • Users are immediately required to change passwords if they are found in newly disclosed breach databases.

6. Passwords are inactivated immediately upon an employee’s termination (refer to the Employee Termination Procedures in HR policy.

7. All default system, application, and Vendor/Partner-provided passwords are changed before deployment to production.

8. Upon initial login, users must change any passwords that were automatically generated for them.

9. Password change methods must use a confirmation method to correct for user input errors.

10. All passwords used in configuration scripts are secured and encrypted, preferably managed through AWS Secrets Manager or equivalent secrets management systems.

11. If a user believes their user ID or password has been compromised, they are required to immediately report the incident to the Security team and change their password.

12. In cases where a user has forgotten their password, password reset procedures provided by the IdP shall be followed. The exact process depends on the system or application. If help is needed, users shall contact IT Support or Security

13. An approved password manager is used to store or share non-critical business application passwords that are not integrated with our primary IdP through SSO.

    • The password manager locally encrypts the password vault with the user’s master password before synchronizing to the cloud.
    • The master password must follow the password requirements listed above (15+ characters).
    • MFA must be enabled in the password manager configuration.
    • Enrollment of the password manager is configured as an application in Google Workspace.

14. An automated process/tool is implemented to ensure compromised passwords or common dictionary words are not used as passwords. This is currently implemented in Google Workspace and supplemented with breach database screening.

Single Sign On

• Bioscope AI selected Google Workspace as its primary Identity Provider (IdP) to control user access to systems and business applications.

• Single sign-on (SSO) should be used whenever possible instead of local authentication. This centralized approach improves user experience and simplifies access management.

• SSO is configured via industry standard SAML protocol between the IdP (Google Workspace) and the target application.

• Security team is responsible for the administration of the IdP / SSO system, including user and access provisioning. Security team may delegate administrative privilege to a subset of the system, such as a specific application.

Multi-factor Authentication

Multi-factor authentication (MFA) is a standard control used by Bioscope AI to provide strong access control to critical systems and applications, and must be enabled for all user accounts, particularly those with access to sensitive data or production systems.

Bioscope AI implements Google Workspace as the primary MFA provider for end-user access, with support for FIDO2/WebAuthn security keys for enhanced protection.

Approved MFA methods (in order of preference):

1. Hardware security keys using FIDO2/WebAuthn protocol

   • Required for privileged accounts (administrators, production access)
   • Strongly recommended for all users with access to ePHI
   • Provides phishing-resistant authentication
   • Examples: YubiKey, Google Titan Security Key

2. Push notification with number matching delivered through the Google Workspace mobile app

   • Default and preferred method for standard end-user access
   • Number matching must be enabled to prevent push notification fatigue attacks
   • Push approvals without number matching are deprecated

3. Time-based One-Time Password (TOTP) delivered through an authenticator mobile app

   • Acceptable alternative when hardware keys are not feasible
   • Examples: Google Authenticator, Microsoft Authenticator, Authy
   • Preferred over SMS for non-privileged accounts

4. Hardware MFA token (non-FIDO2)

   • Required for AWS account root users
   • Acceptable for legacy systems that don’t support FIDO2

5. Device-based cryptographic certificate

   • A unique cryptographic certificate tied to a managed device
   • Used in conjunction with other MFA factors for enhanced security

6. Secure physical facility access control

   • Only acceptable if the system or application can only be accessed from within a secured facility with badge access and monitoring

Prohibited MFA methods:

• SMS text message one-time passcodes - SMS-based MFA is no longer approved due to vulnerabilities including SIM swapping attacks, SS7 protocol exploits, and social engineering risks. Systems currently using SMS MFA must migrate to approved methods.

• Voice call one-time passcodes - Subject to similar vulnerabilities as SMS

• Email-based verification codes - Email accounts may be compromised independently

MFA Requirements:

• All users accessing Bioscope AI systems must have MFA enabled
• Privileged accounts and accounts with access to production systems or ePHI must use phishing-resistant MFA (FIDO2/WebAuthn hardware keys)
• MFA enrollment is required within 24 hours of account creation
• Users must register at least two MFA devices/methods to prevent account lockout
• MFA recovery codes must be generated and stored securely (e.g., password manager)
• MFA devices must be removed immediately upon employee termination or device loss
• Systems must require MFA re-authentication at least every 12 hours for privileged access and every 30 days for standard access

Geographic Context

Access to ePHI (electronic Protected Health Information) is restricted to personnel located within the United States. All personnel with access to ePHI must be physically located in the US.

Bioscope AI employees are all based in the United States. Contractors can be based outside of the United States; however, non-US based contractors do not have access to ePHI.

Employees traveling outside of the United States are expected to notify IT and/or Security. Access to ePHI is suspended while employees are traveling outside the US.

Role Based Access Control (RBAC)

By default, user access is granted based on the user’s job function / role. For example:

• Developer
• Security
• IT
• Administrative
• Marketing / Sales

This is defined as user groups in Google Workspace.

Access to sensitive data including PHI/PII and production customer data is highly restricted and further defined in its own section.

Temporary Access to AWS Accounts and Resources

Bioscope AI implements a zero standing access model for AWS accounts, meaning that users have no persistent permissions by default. All access to AWS resources is granted on a just-in-time basis through temporary credentials and sessions only. No persistent users, passwords or access keys are allowed in AWS IAM configurations for end-user access, either to the AWS console or AWS CLI.

This is achieved through Opal, our access management platform, integrated with AWS Identity Center configured in our bioscope-mgmt management account.

AWS Console Access

• AWS Identity Center is configured in the bioscope-mgmt management account with defined permission sets for different access levels and roles.
• Users authenticate through Google Workspace (our identity provider) using their Google Workspace credentials and MFA.
• To access AWS resources, developers submit just-in-time access requests through Opal, specifying:
  • The specific AWS account they need to access
  • The permission set (role) required for their task
  • Duration of access needed
  • Business justification
• Access requests are evaluated based on the permission level:
  • Standard access to development and non-production environments may be automatically approved based on predefined policies
  • Privileged access to production accounts requires manual approval from engineering leadership
• Upon approval, temporary access is granted through AWS Identity Center, allowing the user to assume the requested role in the specified account
• Access is automatically revoked when the approved time period expires
• All access requests, approvals, and sessions are logged and auditable

AWS CLI/SDK Access

• AWS Identity Center CLI access is obtained using the aws sso login command or similar AWS Identity Center authentication flows
• Users authenticate through the same Opal + AWS Identity Center integration used for console access
• To obtain CLI/SDK credentials:
  • Request access through Opal for the required account and permission set
  • Once approved, use AWS Identity Center to authenticate and obtain temporary credentials
  • Temporary credentials are automatically configured in the local AWS configuration files (e.g., ~/.aws/credentials and ~/.aws/config)
• Temporary credentials automatically expire based on the approved session duration
• CLI/SDK access follows the same approval requirements as console access (automatic for standard access, manual approval for privileged access)

Zero Standing Access and IAM Controls

• Bioscope AI enforces zero standing access through Opal, ensuring no user has persistent permissions to AWS resources
• All access is just-in-time, temporary, and granted only for the specific resources and duration needed
• Permission sets in AWS Identity Center are designed following the principle of least privilege
• Privileged permission sets (such as administrative access to production accounts) require manual approval from engineering leadership
• Access to production environments is highly restricted and monitored
• All access grants, role assumptions, and activities are logged and reviewed regularly for compliance and security auditing

Troubleshooting / Support Access

In normal operations, troubleshooting is performed with log analysis, outside of the production environments in AWS. When direct AWS access is required for troubleshooting:

• Support access is requested through Opal using the same just-in-time access workflow
• Support permission sets are configured with read-only access to necessary services and resources
• Support roles do NOT have permission to make configuration changes and do NOT have access to production data containing ePHI
• All support access requests must be approved by Engineering leadership and Security
• Access is automatically revoked when the approved time period expires
• All support access sessions are logged and auditable

Dual Control for Root Access

Bioscope AI implements a Dual Control / Split Knowledge process to protect the Root user access to our cloud accounts. The process works as follows:

• Security Lead has access to the root account credentials.

  • The credentials are stored encrypted in the the corporate password manager.
  • Security Lead obtains access to the root account in the password manager.

• Engineering Lead has access to the Hardware Tokens associated with the root users.

  • The tokens are stored in secured facility with restricted badge reader access inside a locked safe.

When root access is required for business or operational needs, a Linear ticket is created that requires the Security Lead and Engineering Lead to jointly perform the action.

Remote Access

SSH

• Secure Shell (SSH), when permitted, requires Ed25519 or 4096-bit SHA2 keys.

Access to PHI/ePHI

1. Access to ePHI is permitted to genomics science staff, or staff that otherwise has a business need to access, and has gone through multiple layers of secure access.
2. Bioscope AI has no on-premise server that stores or processes ePHI.
3. Access to ePHI in Bioscope AI’s production environments in the cloud is strictly prohibited. Access is protected via multiple layers of security controls such as IAM policies, restricted IAM roles, VPC configuration, S3 bucket policy, external monitoring, etc.
4. Users may not download ePHI to any workstations or end-user computing devices.

Platform Customer Access to Systems

Bioscope AI does not allow direct system access by customers. Access is only available through the Web UI or API interface, with valid authentication and authorization detailed in the Product Security, Architecture, and Security pages of the engineering wiki.

Access Establishment, Modification and Termination

1. Requests for access to Bioscope AI Platform systems and applications is made formally using the following process:

   1. An access request is created in Linear through either the new employee onboarding request or a specific access request from Bioscope AI IT ticketing system.

   2. The Security team will grant standard access per job role as part of new employee onboarding. A standard set of accounts that are default for all employees are created as part of the onboarding process. This includes

      • User account for local system/laptop
      • Google Workspace user in the Everyone group, and additional group based on role such as Development, IT, Security
      • Slack access to public channels
      • HR accounts for paperwork, benefits management, payroll, expense reporting, etc.
      • Linear access for submitting support requests
      • Additional role based access (e.g. GitHub and aws-dev access for a developer)

   3. Standard access may be provisioned at any time by account owners/administrators during or after onboarding with approval of account owners and/or manager.

   4. If additional access is needed in addition to the above, a separate access request (through Linear) is required and the requester must include a description and justification as part of the access request.

   5. Once the review is completed, the Security team approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.

   6. If the review is approved, IT or Security team provisions access, then marks the Issue as Done, adding any pertinent notes required.

      • New accounts will be created with a temporary secure password that meets all password requirements, which must be changed on the initial login.
      • All password exchanges must occur over an authenticated channel.
      • For cloud accounts, access grants are provisioned in Google Workspace or using the access control mechanisms built into those services/applications.
      • Account management for non-production systems may be delegated to a Bioscope AI employee at the discretion of the Security Officer.

2. Special access, including access to production environments, is not granted until receipt, review, and approval by the Bioscope AI Security Officer.

3. The request for access is retained for future reference.

4. Temporary accounts are not used unless absolutely necessary for business purposes.

   • Accounts are reviewed every 90 days to ensure temporary accounts are not left unnecessarily.
   • Accounts that are inactive for over 90 days are removed.

5. In the case of non-personal information, such as generic educational content, identification and authentication may not be required.

Access Termination

IT Manager or Security team receives access termination requests in one of the following conditions and processes it accordingly:

• Employee departure/termination, as defined by the process in HR & Employee Security;
• Employee access to a system is no longer required as a result of job role change or similar event, in which case an access termination request may be submitted by the employee or his/her manager via the IT ticket system or an email request to Security team;
• As the result of a Access Review, as defined in System Auditing.
• Non-standard access is revoked by default after 30 days of inactivity, unless an exception/extension is requested and approved.

Access Reviews

• All access to Bioscope AI systems and services are reviewed and updated following the procedures specified in System Auditing to ensure proper authorizations are in place commensurate with job functions.
• In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security and Privacy Officer to limit access and reduce risk of unauthorized access.

Privileged Access

Privileged users must first access systems using standard, unique user accounts before elevating the privilege or switching to privileged users and performing privileged tasks. Examples include:

• sudo in Linux/MacOS
• Assume role in AWS

Service Accounts

• All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.

• Services that are part of Bioscope AI platform leverage AWS IAM policy configurations and/or OAuth for authorization.

• Generic accounts are not allowed on Bioscope AI systems.

• Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.

• In AWS, service accounts are implemented in the form of IAM Roles, and their access defined by the corresponding IAM policies. The creation of these IAM roles and policies is implemented as code, which follows the secure development, review and production change approval process.

• An inventory of all Service accounts is maintained by AWS IAM and Terraform and reviewed periodically.

Employee Workstation / Endpoints Access and Usage

All workstations at Bioscope AI are company owned, using one the following approved hardware vendors and operating systems:

• Apple
• MacOS, Linux (Ubuntu or Debian)

1. Workstations may not be used to engage in any activity that is illegal or is in violation of organization’s policies.
2. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through organization’s system.
3. Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
4. Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
5. Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
6. Workstation hard drives will be encrypted using FileVault (MacOS) or equivalent.
7. All workstations must have host firewalls enabled to prevent unauthorized access unless explicitly granted.
8. All workstations must have endpoint security software installed and actively running, if supported by the operating system.

Office Network and Wireless Access

1. Bioscope AI production systems are not accessible directly over wireless channels.
2. Wireless access is disabled on all production systems.
3. When accessing production systems via remote wireless connections, the same system access policies and procedures apply to wireless as all other connections, including wired.

Production Access and Secrets Management

Bioscope AI leverages a combination of AWS Secrets manager and Github Actions Secrets to securely store production secrets. Secrets are always encrypted; access to secrets is always controlled and audited.

Details and usage are documented on the Bioscope AI Engineering Wiki.

Production Data Access

The following requirements and controls are in place for accessing production data by internal personnel:

• There is no pre-provisioned, persisted “internal” access to production data stores. Access such as direct SSH to the production database servers and direct access to data objects in production S3 buckets are prohibited.

• Access to customer data is granted on a per-account basis.

• Access requests follow the same production access processes. Access must be approved by both the data owner and the security team.

• Access to production data is granted only through approved platform with strong centralized access control, with MFA.

• An audit list of who has access to which customer data is maintained and reviewed monthly. Access is revoked when no longer needed.

Password Reset and other Helpdesk Requests

Bioscope AI employees have the ability to obtain self-service support directly from supported business applications, such as password reset via the SSO/IdP tool.

If needed, users may reach out to obtain IT and Security support.

A ticket is opened in Linear for each support request and assigned to the appropriate personnel. The person assigned must verify the identity of the requester and ensure the ticket has appropriate approval before implementing or providing support. The verification step and confirmation of “User identity verified” should be included as a comment in the ticket by the support personnel. Additionally, if a password or security credential has been created or supplied, confirm user has received it via another channel like slack/email/phone/zoom and document receipt in the ticket.