Security Settings
Your CSV (Computer System Validation) team is reviewing ProBeya for deployment in a GxP-regulated manufacturing environment. They need to verify that the platform meets 21 CFR Part 11, EU Annex 11, and your internal security policies. This page documents every security configuration available in ProBeya, its compliance impact, and the recommended settings for regulated deployments.
Organization admins can configure security settings in Settings > Security.
21 CFR Part 11 Compliance Checklist
Use this checklist to verify ProBeya's configuration meets regulatory requirements before go-live:
| 21 CFR Part 11 Section | Requirement | ProBeya Setting | Recommended Configuration |
|---|---|---|---|
| 11.10(a) | System validation | Platform qualification | Document IQ/OQ/PQ per GAMP 5 |
| 11.10(d) | Authority checks / unique users | MFA + SSO enforcement | Enable org-wide 2FA; enforce SSO |
| 11.10(d) | Access controls | Role-based permissions | Configure per Roles & Permissions |
| 11.10(e) | Audit trail | Activity log | Enterprise plan required for full log |
| 11.10(g) | Session controls | Session timeout | Set to 30 minutes for production systems |
| 11.10(g) | Open system safeguards | IP allowlisting | Restrict to corporate network CIDRs |
| 11.300(b) | Electronic signature binding | MFA on critical operations | Enable 2FA for all members |
| EU Annex 11, s12.1 | Physical/logical access | IP allowlisting + SSO | Combine network restriction with IdP auth |
| EU Annex 11, s12.4 | Password management | Password policy | Enforce 12+ chars, complexity, 90-day expiry |
Two-Factor Authentication (2FA)
Enabling 2FA for Your Account
- Go to your Profile Settings > Security.
- Click Enable Two-Factor Authentication.
- Scan the QR code with an authenticator app (Google Authenticator, Authy, 1Password, Microsoft Authenticator).
- Enter the 6-digit TOTP code to verify.
- Save the recovery codes in a secure location.
TOTP configuration parameters:
| Parameter | Value | Notes |
|---|---|---|
| Issuer | ProBeya | Displayed in authenticator app |
| Algorithm | SHA1 | Industry standard for TOTP (RFC 6238) |
| Digits | 6 | Standard TOTP code length |
| Period | 30 seconds | Code rotation interval |
Backup Codes
When MFA is enabled, 10 backup codes are generated in the format XXXX-XXXX (8 uppercase hex characters with a hyphen). Security properties:
- Shown only once at setup time -- save them immediately to a secure vault or printed sheet.
- Stored as bcrypt hashes in the database (never in cleartext).
- Each code can be used only once as a one-time login fallback.
- New backup codes can be regenerated at any time, which invalidates all previous codes.
For GxP environments, backup codes should be stored in a controlled document system (e.g., a sealed envelope in a physical safe or an enterprise password vault with audit logging). Include the backup code storage procedure in your SOP for system access.
Enforcing 2FA Organization-Wide
Organization admins can require all members to enable 2FA:
- Go to Settings > Security.
- Toggle Require 2FA for all members.
- Set a grace period (e.g., 7 days) before enforcement takes effect.
- Members who have not set up 2FA will be prompted on their next login.
The organization MFA status dashboard shows adoption metrics:
- Total members with MFA enabled
- Members in grace period (pending setup)
- Non-compliant accounts (past grace period)
Enabling org-wide 2FA enforcement affects all members including guests. Ensure external auditors and consultants with guest access have authenticator apps before enabling enforcement without a grace period.
Single Sign-On (SSO) -- Enterprise
Enterprise plan customers can configure SSO with SAML 2.0 or OpenID Connect. See the dedicated SSO page for full configuration details.
SSO Enforcement Modes
| Mode | Behavior | Security Level | Use Case |
|---|---|---|---|
| Allow both SSO and password | Members can log in either way | Standard | Transition period during SSO rollout |
| SSO only | Disables password login for non-admin members | High | Production GxP environment |
When enforcing SSO-only login, ensure at least one org_owner retains password access as a break-glass measure. Document this in your disaster recovery SOP.
Session Management
Configure session policies in Settings > Security > Sessions:
| Setting | Default | GxP Recommended | 21 CFR Part 11 Reference |
|---|---|---|---|
| Session timeout | 7 days | 30 minutes | 11.10(g) -- prevent unauthorized access from unattended sessions |
| Maximum sessions | Unlimited | 2 | 11.10(d) -- limit concurrent access per user identity |
| Force logout | Manual | As needed | 11.10(d) -- immediately terminate sessions for departing users |
Session management helps comply with 21 CFR Part 11 requirements for controlled access. For production environments, a 30-minute inactivity timeout is the industry standard.
Password Policies
Set minimum requirements for member passwords:
| Policy | Default | GxP Recommended | Rationale |
|---|---|---|---|
| Minimum length | 8 | 12+ | NIST SP 800-63B recommends 8+; pharma industry standard is 12+ |
| Require uppercase | Off | On | Increases character space |
| Require number | Off | On | Required by most pharma SOPs |
| Require special char | Off | On | Required by most pharma SOPs |
| Password expiry | Off | 90 days | 21 CFR Part 11 does not mandate rotation, but most pharma QMS SOPs require it |
Password expiry alone does not prevent compromise. Combine it with 2FA enforcement and SSO for defense-in-depth. NIST SP 800-63B recommends against mandatory rotation unless there is evidence of compromise, but many pharma quality systems still require it.
IP Allowlisting (Enterprise)
Restrict access to your organization from specific IP addresses or CIDR ranges:
- Go to Settings > Security > IP Allowlist.
- Add IP addresses or CIDR ranges (e.g.,
198.51.100.0/24). - Enable the allowlist.
Enabling IP allowlisting can lock you out if your own IP is not included. Before enabling:
- Add your current IP address.
- Add your VPN exit IPs.
- Add the IP ranges of all sites that need access.
- Test with a single admin account before enabling for the full org.
- Document the allowlist in your network architecture diagram.
Enterprise IP Strategy
| Network Segment | CIDR Example | Purpose |
|---|---|---|
| Corporate HQ | 198.51.100.0/24 | Office-based access |
| Brussels Site VPN | 203.0.113.0/25 | Manufacturing site access |
| Dublin Site VPN | 203.0.113.128/25 | Manufacturing site access |
| Remote VPN Pool | 10.8.0.0/16 | Home/travel worker access via VPN |
Audit Trail
All security-related actions are logged to the activity log with immutable timestamps and actor identification:
| Event Category | Logged Actions | Compliance Reference |
|---|---|---|
| Authentication | MFA enable/disable, backup code regeneration | 21 CFR Part 11.10(e) |
| SSO | Configuration changes, activation, deactivation | 21 CFR Part 11.10(e) |
| Session | Forced terminations, timeout changes | 21 CFR Part 11.10(g) |
| Password | Policy changes, forced resets | EU Annex 11, s12.4 |
| IP Allowlist | Rule additions, modifications, enablement | SOC 2 CC6.1 |
| Role Changes | Permission modifications, role assignments | 21 CFR Part 11.10(d) |
These events support compliance requirements (21 CFR Part 11, EU Annex 11, GDPR Article 30) and security incident investigation. The audit trail is append-only -- entries cannot be modified or deleted.
Security Architecture Summary
User → IP Allowlist → SSO / Password Auth → 2FA Challenge
↓
Session Created (timeout + max sessions enforced)
↓
Role-Based Permission Check (23 permissions)
↓
Tenant-Scoped Data Access (organizationId filter)
↓
Audit Trail Entry (immutable, timestamped)
Recovery Procedures
| Scenario | Resolution |
|---|---|
| User locked out of 2FA | Use one of the 10 backup codes. If all codes are exhausted, an org_owner can disable 2FA for the user. |
| All admins locked out (IP allowlist misconfigured) | Contact ProBeya support with the billing email address for emergency IP allowlist reset. |
| SSO outage prevents all logins | An admin with password access deactivates SSO enforcement. See SSO Recovery. |
| Suspected compromised account | Force-logout all sessions for the user, disable their 2FA, reset their password, and review the audit log. |
| Password policy change locked out existing users | Users whose passwords no longer meet the new policy are prompted to change on next login, not locked out retroactively. |
Related Features
- SSO -- Detailed SSO configuration guide.
- Roles & Permissions -- Control who can manage security settings.
- Audit Log -- All security events are recorded.
- GDPR Compliance -- Data protection and privacy settings.