Security

Ward is designed for healthcare environments with strict security and compliance requirements.

Data Protection

Encryption

Data State	Encryption
In transit	TLS 1.3
At rest (server)	AES-256
At rest (mobile)	AES-256-GCM
Backups	AES-256

All cloud communication uses HTTPS. Local hub diagnostics use HTTP on the facility LAN. Database storage and backups are encrypted.

Offline data cached on mobile devices is encrypted using AES-256-GCM with keys stored in the iOS Secure Enclave or Android Keystore. Keys never leave the device.

Access Control

Row Level Security (RLS) ensures data isolation:

• Staff only access their facility's data
• Role-based access controls limit functionality
• API keys scoped to specific devices

Authentication:

• Password-based (minimum 12 characters)
• Optional SSO via SAML 2.0 (Okta, Microsoft Entra ID, PingIdentity) or OIDC
• Multi-factor authentication (TOTP via authenticator apps)
  • Required for elevated roles (Charge Nurse, Unit Manager, Director, Admin, IT Admin)
  • Optional for Staff role
• Progressive account lockout after failed login attempts
• Session management with secure tokens
• Automatic session expiration
• Biometric re-authentication after 5 minutes of app inactivity (Face ID, Touch ID, or device passcode)

Account Lockout:

Ward protects against brute-force attacks with progressive lockout:

Failed Attempts	Lockout Duration
5 in 15 minutes	15 minutes
10 in 1 hour	1 hour
15 in 24 hours	Permanent (admin unlock required)

Administrators can unlock accounts from the Staff management screen.

Audit Logging

All writes to patient data are logged:

• Who made the change
• When the change occurred
• What action was taken (create, update, acknowledge, resolve)

Logs retained per facility retention policy (minimum 7 years).

Mobile App Security

Ward's mobile app includes multiple layers of protection for patient data:

Screen Capture Prevention

Screenshots and screen recordings are blocked on iOS and Android. This prevents accidental or intentional capture of patient information displayed on screen.

Biometric Lock

After 5 minutes of app inactivity (when the app is in the background), users must re-authenticate using Face ID, Touch ID, or their device passcode before accessing the app.

Device Security Checks

Ward performs security checks on launch:

• Root/jailbreak detection: Detects if the device has been compromised
• Emulator detection: Identifies if the app is running on an emulator

If a device fails these checks, a warning banner is displayed. The app remains functional (clinical workflows must continue) but users are alerted to the security risk.

Network Security

Cleartext (HTTP) traffic is blocked at the OS level on both iOS and Android. All network communication uses HTTPS.

HIPAA Compliance

Ward supports HIPAA compliance:

Technical Safeguards

• Access controls (unique user IDs, role-based access)
• Audit controls (comprehensive logging)
• Integrity controls (data validation, database constraints)
• Transmission security (TLS encryption)

Administrative Safeguards

• Business Associate Agreement (BAA) with infrastructure provider
• Incident response procedures
• Risk assessments

Physical Safeguards

Supabase infrastructure provides:

• Facility access controls
• Workstation security
• Device and media controls

Database Security

Multi-Tenant Isolation

All database queries enforce facility-level isolation:

• Row Level Security (RLS) policies prevent cross-facility data access
• Privileged database functions validate the caller's facility before operating
• API requests cannot specify a different facility ID

Data Integrity

• Only administrators can modify staff roles
• Clinical data cannot be created for discharged patients
• Duplicate submissions are automatically rejected

Credential Management

User Passwords

• Minimum 12 characters
• Passwords hashed by Supabase Auth (bcrypt)
• Never stored in plain text
• Never logged

API Keys (Sensor Hubs)

• Generated with cryptographic randomness (256-bit)
• Stored as SHA-256 hash in hub config (cannot be retrieved)
• Displayed exactly once at registration
• Scoped to specific devices
• If lost, hub must be deactivated and re-registered

EMR Credentials

• Client secrets encrypted at rest
• Never logged or displayed
• Access limited to IT admins

Network Security

Firewall

• Only HTTPS (443) exposed publicly
• Internal services use private networking
• Sensor hubs connect via outbound HTTPS only

DDoS Protection

• Rate limiting on sensor and EMR ingest endpoints
• Cloud provider DDoS mitigation

Vulnerability Management

Code Security

• Static analysis (Semgrep) in CI/CD
• Dependency scanning (npm audit)
• No medium+ severity findings allowed
• Regular security reviews

Penetration Testing

• Internal penetration testing completed Q2 2026, with findings remediated
• Third-party external penetration test scheduled for Q2 2027
• Penetration test reports available to customers upon request

Incident Response

1. Detection: Automated monitoring and alerting
2. Containment: Isolate affected systems
3. Eradication: Remove threat
4. Recovery: Restore normal operations
5. Lessons Learned: Post-incident review

Customers notified within 72 hours of confirmed breaches.

Data Retention

Data Type	Active	Archive	Total
Observations	1 year	6 years	7 years
Alerts	1 year	6 years	7 years
Vitals	1 year	6 years	7 years
Assessments	1 year	6 years	7 years
Audit logs	1 year	6 years	7 years
Sensor events	90 days	—	90 days

Configurable per facility based on regulatory requirements.

Compliance

• HIPAA: Business Associate Agreement available for all customers
• Infrastructure: Hosted on Supabase (SOC 2 Type II certified, HIPAA eligible)
• Encryption: AES-256 at rest, TLS 1.3 in transit
• Audit logging: Comprehensive access logging retained per facility policy

Security Contacts

Report security vulnerabilities to:

Email: security@ward.health

We follow responsible disclosure practices and acknowledge reports within 48 hours.