ALY: Telehealth Security Architecture

The Challenge

ALY is a telehealth platform connecting patients with healthcare providers. In healthcare, security isn't a feature. It's the foundation. The platform needed to be HIPAA-compliant from the first commit, with encryption, access control, and audit trails architected into every layer.

The real challenge wasn't checking compliance boxes. It was building a security architecture that could survive penetration testing, pass regulatory audits, and scale with ALY, all without making the user experience sluggish for patients and providers.

If you're a high-growth healthtech company, you know the pressure: investors want product velocity, but regulators want airtight compliance. Your engineering team is shipping features fast, and the last thing you need is a six-month compliance project that freezes your roadmap. ALY faced exactly this tension. They needed a team that could design HIPAA-compliant security architecture and production-grade cloud infrastructure in parallel with product development. We took that on.

Here's what we built, and why.

Architecture Overview

ALY runs on Azure with a defense-in-depth strategy: multiple layers of security, each independent, so a breach in one layer doesn't compromise the entire system.

The Stack

Backend: .NET 6+ Web API hosted on Azure App Service with auto-scaling policies, health checks, and multi-region failover. .NET was the right pick here: battle-tested in healthcare, strong cryptographic libraries, and native integration with Azure's security tooling.

Frontend: Angular SPA with strict Content Security Policy (CSP), CSRF token validation on every mutating request, and XSS protection via Angular's built-in sanitization. Frontend is served through Azure CDN with HTTPS-only enforcement.

Mobile: Flutter for iOS and Android. Single codebase, but platform channels handle native biometric authentication (Face ID, Touch ID, Android fingerprint). Biometric auth matters in healthcare; it's faster than passwords and more secure than SMS-based MFA.

Database: Azure SQL Server with Transparent Data Encryption (TDE). Every page of data is encrypted at rest with AES-256. Backups are encrypted automatically. Key rotation is handled by Azure Key Vault.

Serverless: Azure Functions for background jobs: appointment reminders, notification pipelines, audit log aggregation. Serverless gives us elastic scale and reduces attack surface (no long-running servers to patch).

Security Architecture: Layers of Defense

Security in healthcare isn't about one lock on the door. It's about multiple locks, each using a different key, with cameras watching everyone who approaches.

Layer 1: Authentication (Who Are You?)

Multi-factor authentication (MFA) is enforced across all user types: patients, providers, administrators. Not optional. It's enforced at the identity provider level.

MFA Options:

• Authenticator apps (TOTP)
• SMS codes (fallback for patients without smartphones)
• Email verification (lowest security tier, used only for account recovery)
• Biometric authentication on mobile (Face ID, fingerprint)

Risk-Based Adaptive Authentication: Login patterns are tracked continuously. If a provider who normally logs in from New York suddenly logs in from Moscow, the system forces a step-up authentication challenge. Same for unusual device fingerprints or VPN usage.

Layer 2: Authorization (What Can You Do?)

Authentication tells us who you are. Authorization tells us what you're allowed to do.

Access control uses Role-Based Access Control (RBAC) with granular permissions. Roles define broad categories (Patient, Provider, Nurse, Admin), and permissions control specific actions (view_patient_records, prescribe_medication, modify_billing).

Example: A nurse can view patient vitals and update care notes, but can't prescribe medication or access billing information. This is enforced at the API layer, so even if a malicious actor compromises the frontend, they can't bypass authorization.

Token Management: JWT tokens have short expiration windows (15 minutes for access tokens, 7 days for refresh tokens). On credential changes, password resets, or suspicious activity, all tokens are invalidated immediately. The user has to re-authenticate.

Layer 3: Encryption (Protect the Data)

In Transit: Every byte of data moving between client and server is encrypted with TLS 1.2 or higher. We enforce HTTPS at the CDN level and reject any HTTP requests.

At Rest: SQL Server uses Transparent Data Encryption (TDE) with AES-256. Every database page is encrypted before being written to disk. Backups are encrypted automatically. Keys are managed by Azure Key Vault with automated rotation.

Key Management: Azure Key Vault stores all secrets: database connection strings, API keys, encryption keys. Keys rotate automatically every 90 days. No secrets in environment variables or config files.

Layer 4: Network Security (Control the Perimeter)

Network Security Groups (NSGs): NSGs control all inbound and outbound traffic. The database only accepts connections from the API servers. The API servers only accept HTTPS traffic on port 443. Everything else is denied by default.

IP Whitelisting: Administrative access to the database and Azure Functions is restricted to known IP ranges. Even if an attacker steals admin credentials, they can't connect from an unauthorized IP.

Environment Segmentation: Dev, staging, and production are completely isolated. Separate Azure subscriptions, separate databases, separate Key Vaults. A vulnerability in dev can't propagate to production.

Layer 5: Monitoring & Incident Response

Security isn't "set it and forget it." You have to watch the system constantly.

Real-Time Monitoring:

• DDoS detection and automatic mitigation via Azure DDoS Protection
• Latency monitoring, with alerts triggered if API response times exceed thresholds
• Failed login attempt tracking: rate limiting after 5 failed attempts, account lockout after 10
• Azure service health monitoring; instant notifications if Azure reports an incident affecting our region

Comprehensive Audit Trails: Every user action, system event, and security incident is logged with timestamps, user IDs, IP addresses, and action types. Logs are immutable (write-once, read-many) and stored for 7 years to meet HIPAA retention requirements.

Automated Alerting: Alerting rules notify the security team immediately when anomalies are detected:

• Sudden spike in failed login attempts (potential credential stuffing attack)
• Database queries returning unusually large result sets (potential data exfiltration)
• Access attempts from blacklisted IPs or countries
• Privilege escalation attempts (a user trying to access resources outside their role)

Penetration Testing: Annual penetration tests are run with third-party security firms. They attempt to breach the system using every technique in the playbook: SQL injection, XSS, CSRF, privilege escalation, session hijacking. Every finding is triaged, patched, and re-tested.

HIPAA Compliance

HIPAA isn't a checklist. It's a framework. But here's how we aligned ALY's architecture with HIPAA's core requirements:

Administrative Safeguards:

• Security risk assessments performed during design phase and annually thereafter
• Security policies documented and enforced via code review and automated testing
• Workforce training on HIPAA requirements (though this was client-side, we provided technical training on secure coding practices)

Physical Safeguards:

• US-hosted servers (Azure regions in East US and West US) to meet data residency requirements
• Azure's physical security controls (biometric access, 24/7 monitoring, etc.) inherited through cloud hosting

Technical Safeguards:

• Access controls (MFA, RBAC, least privilege)
• Audit controls (comprehensive logging and monitoring)
• Integrity controls (checksums on data transfers, TDE for data at rest)
• Transmission security (TLS 1.2+ for all network traffic)

Encryption Standards: AES-256 for data at rest, TLS 1.2+ for data in transit. Keys managed via Azure Key Vault with automatic rotation.

Secure SDLC: Security requirements were integrated from the design phase. Every feature went through threat modeling, secure coding review, and security testing before deployment.

Compliance Roadmap

Getting to HIPAA compliance is a journey, not a checkbox. This is the phased approach we used with ALY, and the same framework we apply to every healthcare engagement. Each phase builds on the last, so nothing gets bolted on as an afterthought.

Key insight: compliance work and product development don't have to be sequential. With the right architecture decisions made early (Phase 2), your engineering team can ship features during Phase 3 without creating security debt. Building security in from day one versus bolting it on later makes all the difference.

Disaster Recovery & Business Continuity

Healthcare systems can't go down. Downtime means patients can't reach providers, which can have life-or-death consequences.

Automated Backups: SQL Server backups run every 6 hours, with full weekly backups and daily differential backups. All backups are encrypted and stored in geo-redundant Azure Blob Storage (data replicated to a secondary region).

Backup Verification: Backups are useless if they don't restore. Monthly restore tests ensure backups are valid and can be restored within the RTO (Recovery Time Objective) of 4 hours.

Disaster Recovery Plan: Documented procedures for restoring service in the event of a regional Azure outage, database corruption, or security breach. The plan includes contact lists, escalation procedures, and step-by-step technical runbooks.

The Engineering Decisions That Mattered

Why Azure Over AWS?

ALY's engineering team already had .NET expertise, and Azure's native integration with .NET tooling reduced friction. Azure Key Vault, Azure SQL, and Azure Functions work seamlessly with the .NET SDK. AWS would have required more custom integration work.

Why Flutter Over Native?

Flutter gave us a single codebase for iOS and Android, which meant faster iteration and fewer security vulnerabilities (one codebase to audit instead of two). The performance is near-native, and Flutter's platform channels let us access native biometric APIs when needed.

Why RBAC Instead of ABAC?

Attribute-Based Access Control (ABAC) is more flexible than RBAC, but it's also more complex. In healthcare, roles are well-defined (Patient, Provider, Nurse, Admin), so RBAC was a better fit. Permission-based granularity within roles handles edge cases.

Why Serverless for Background Jobs?

Azure Functions let us scale background jobs independently from the API servers. During peak hours (mornings when patients book appointments), the API servers scale up, but the background job load stays constant. Serverless also reduces attack surface since there are no long-running servers to patch or harden.

The Outcome

ALY launched with a security posture that most healthcare startups take 2-3 years to build. The platform passed its initial security audit without major findings. The architecture scales with both user growth and compliance requirements (SOC 2, GDPR, state-level regulations) as ALY expands into new markets.

Key Metrics:

• Zero security incidents in the first 12 months post-launch
• 99.95% uptime (Azure SLA + our monitoring and failover policies)
• <200ms average API response time (critical for real-time telehealth sessions)
• Passed penetration testing with zero critical or high-severity findings

ALY's architecture isn't just compliant. It's resilient. In healthcare, that's what actually matters.

How the Layers Work Together

The real value of defense-in-depth is that no single layer is a single point of failure. Each layer operates independently, so a compromise at one level doesn't cascade through the system.

Each ring you see above is independent. If an attacker gets past the network layer, they still face MFA. Past MFA, they hit role-based permissions. Past permissions, everything is encrypted. And the monitoring layer watches all of it in real-time.

Work With Us

If you're building in healthcare and need to get HIPAA-compliant without putting your product roadmap on hold, let's talk. We've done this for telehealth platforms, clinical data systems, and patient-facing applications, and we bring the same defense-in-depth approach every time.

Best fit: funded healthtech startups with a product in motion that need security engineering embedded in the development process, not layered on top of it.

Explore our Security & Compliance and Cloud Architecture services, or come talk to us directly on Discord.