By Outcome — Modernize & Comply

HIPAA Security Rule controls on one platform — on your own network

ePHI stays inside your network. The application-edge HIPAA controls run on one TR7 platform.

The HIPAA Security Rule's Technical Safeguards (164.312) describe a control surface that lives almost entirely at the application edge — encrypt ePHI in transit, control who can reach it, authenticate every account, record who did what, and prove the integrity of the data on the wire. The two classic ways to land these controls are both expensive. A bolt-on kit: a WAAP module from one vendor, an access module from another, a multi-tenancy add-on, a data masking add-on — each priced separately, each with its own operator console. Or moving ePHI traffic to a third-party cloud edge, where the path between the user and the clinical application is no longer yours to inspect. TR7 offers a third way. The same platform that delivers and protects your modern services covers the HIPAA controls that live at the application edge — TLS termination with modern ciphers, WAAP in front of every clinical application, MFA at the access edge, vTenant isolation between ePHI and non-ePHI workloads, PHI masking on responses, and centralized audit — on one TR7, on the network you already operate. ePHI stays inside your network. The audit trail stays under your governance.

Security Rule
Application-edge controls under 164.312 and parts of 164.308 covered on one platform
One platform
TLS, WAAP, MFA, vTenant, PHI masking and audit all on the same TR7 — no separate modules
Your network
ePHI and audit logs stay inside your network — no third-party edge in the path

Two costly paths for HIPAA — and the third one most clinical operations teams actually want

A clinical operations team's HIPAA Security Rule scope reaches a moment of truth at the application edge. Patient portal traffic terminates here. EHR access decisions are made here. ePHI flows in and out here. The Technical Safeguards under 164.312 — encrypt in transit, control access, authenticate users, audit activity, preserve integrity — are almost entirely application-edge controls. So is most of 164.308's Information Access Management.

The classic responses are both expensive. The bolt-on kit: a WAAP module from one vendor, an access module with MFA from another, a multi-tenancy add-on for multi-site organizations, a data masking add-on for PHI patterns — each licensed separately, each with its own operator console, each integrated by your team. The cloud edge: move ePHI traffic to a third-party WAAP and put the path between the user and the clinical application on someone else's platform — efficient until your governance team asks where ePHI is being inspected and your answer involves a contract clause.

The third path is the one most clinical operations teams actually want: one platform that covers the HIPAA controls that live at the application edge, on the network already inside the audit boundary. TR7 is built for that path. TLS, WAAP, MFA at every account that reaches ePHI, vTenant isolation, PHI masking and audit on the same TR7. The auditor asks for the artifacts; one operator console produces them.

Six controls TR7 brings to HIPAA at the application edge

Each control matters on its own. Taken together, they describe what HIPAA compliance looks like when the application edge runs on a single platform you already operate.

Transmission Security — ePHI encrypted at the edge (164.312(e))

TLS termination on the TR7 edge with modern ciphers, current certificates, OCSP stapling, HSTS and the option to enforce mTLS where the use case allows. ePHI on the wire meets the 164.312(e)(2)(ii) encryption expectation before it reaches the clinical backend.

Access Control + auto-logoff (164.312(a))

AAM Per-Service Authentication wraps every ePHI-facing application with unique user identification, role-based access policy, configurable session timeouts and auto-logoff. The clinical application receives the user identity it expects; TR7 enforces the access control surface in front of it.

Person/Entity Authentication — MFA at the access edge (164.312(d))

MFA enforced at the edge for every account reaching ePHI through TR7 — clinical staff, administrators, contractors, service accounts. OIDC, SAML, TOTP, FIDO2 native. The HHS 2024-12-27 Notice of Proposed Rulemaking removes the "addressable" classification from MFA and makes it mandatory; TR7 is already aligned with that model.

ePHI environment isolation — vTenant + QoS + routes

vTenant provides administrative, operational and observational isolation between ePHI and non-ePHI workloads on the same TR7 infrastructure. QoS pools give clinical traffic its own bandwidth envelope; per-vService route tables keep ePHI-bound flows distinct. For multi-site healthcare organizations and BAA service providers, vTenant scales the isolation to many tenants without a separate appliance per site or per client.

PHI masking on responses (minimum-necessary, 164.502(b))

TR7 detects PHI patterns — medical record numbers, names, dates of birth, identifiers — in API and HTML responses and masks them per policy before they leave the application edge. Supports the minimum-necessary disclosure principle for outputs to staff with narrower roles, without changing application code.

Audit Controls (164.312(b)) — centralized and command-level

Access events, traffic decisions, WAAP detections, MFA outcomes and SSH sessions to clinical infrastructure share one audit trail. SSH command-level capture for administrative sessions is investigation-ready without a separate PAM product. SIEM export uses a consistent taxonomy across the platform — the artifacts an assessor or breach investigator asks for come from one place.

What TR7 brings to a HIPAA programme

Every capability below runs on the same TR7 platform that delivers and protects your modern services.

TLS termination at the edge with modern ciphers

Current TLS versions, modern cipher suites, OCSP stapling, automatic certificate management. Optional mTLS where appropriate. Supports 164.312(e) Transmission Security expectations on ePHI in transit.

WAAP in front of patient portals, telehealth and EHR-facing applications

10,000+ signatures plus an 11-factor scoring engine. OWASP categories, framework-specific protections for common healthcare stacks, CWE/CAPEC/MITRE mapping for audit and incident traceability. Inline blocking or detect-only modes.

Modern SSO over legacy EHR authentication

AAM Per-Service Authentication wraps a legacy EHR or clinical application with OIDC or SAML SSO from your IdP. The legacy backend receives the credential artifact it expects; clinical staff authenticate the modern way with MFA. Useful for EHR-fronted portals where the underlying clinical system cannot be changed by the customer.

MFA for every account reaching ePHI

Multi-factor authentication at the access edge for every account that touches ePHI through TR7. Step-up authentication when context changes — different device, different geography, sensitive resource. Aligned with the HHS 2024 NPRM direction on mandatory MFA.

Clientless RDP, SSH and VNC for clinical admin

Browser-based access to medical device controllers, PACS workstations, lab instruments, EHR admin consoles. No native client on the operator endpoint. Sessions tunneled and audited at the command level; one revoke ends every active session.

Auto-logoff and configurable session timeouts

Per-application session timeouts enforce auto-logoff at the access edge, satisfying 164.312(a)(2)(iii) without changes to clinical application code. Step-up reauthentication when the session continues past policy thresholds.

vTenant for multi-site healthcare and BAA service providers

Multi-tenant isolation at the platform level. Hospital chains, regional health systems and clinical SaaS providers can give each site, business unit or customer its own administrative, operational and observability boundary. ePHI-scoped tenants run alongside non-ePHI tenants without commingled configuration, audit or traffic.

QoS pools and dedicated route tables

ePHI traffic in its own bandwidth envelope; ePHI-bound flows in dedicated route tables. Network segmentation between clinical and non-clinical workloads — exactly the segmentation direction the HHS 2024 NPRM proposes to make mandatory.

PHI masking — MRN, names, identifiers on responses

Configurable pattern masking on outbound responses. Medical record numbers, patient names, dates of birth, identifiers truncated or suppressed per role policy. Supports the minimum-necessary disclosure principle on the egress path.

Non-HTTP clinical traffic on the same platform

HL7 over TCP between systems, DICOM-style imagery for radiology workflows, FTP for lab data exchange, plain TCP/UDP for clinical instruments — purpose-built listeners on the same engine as the HTTP WAAP. One platform, one operator console, one audit trail.

Centralized audit and SIEM export

One audit trail across delivery, security, access and DDoS layers. SIEM export with consistent taxonomy. Supports 164.312(b) Audit Controls and 164.308(a)(1)(ii)(D) Information System Activity Review obligations on the application edge.

Command-level SSH audit for administrative sessions

SSH sessions reaching clinical infrastructure through the TR7 gateway are captured at the command level — every command, every response. Investigation-grade audit for the privileged access HIPAA Security Rule cares about, without a separate PAM product.

On-prem first — ePHI stays inside your network

TR7 runs on your hardware, in your data centre, under your network controls. ePHI traffic and audit logs do not transit a third-party edge. No business associate agreement is needed for the TR7 platform itself because TR7 does not host your ePHI — the platform runs in your environment.

How TR7 maps to the HIPAA Security Rule

TR7 covers a specific surface of the HIPAA Security Rule — the application edge. The map below is honest about what that does and does not include.

01

164.312(a) — Access Control

Unique user identification via AAM and your IdP. Emergency access procedures via per-tenant break-glass flows. Automatic logoff via configurable session timeouts at the access edge. Encryption/decryption of ePHI in transit via the TLS edge. All enforced in front of the clinical application, without code changes.

02

164.312(b) — Audit Controls

Centralized record and review across access events, WAAP detections, MFA outcomes, traffic decisions and command-level SSH sessions. SIEM export with consistent taxonomy. Configurable retention. Investigation-grade artifacts on demand.

03

164.312(c) — Integrity (partial)

TLS in transit provides cryptographic integrity on the wire. Content-aware response inspection detects unauthorized modification of outbound content. Integrity at rest is a storage-layer concern that complements rather than overlaps with the application-edge layer.

04

164.312(d) — Person/Entity Authentication

MFA enforced at the access edge through AAM. Native OIDC, SAML, TOTP, FIDO2. Step-up authentication when context changes. The HHS 2024 NPRM direction making MFA mandatory aligns with how TR7 already deploys.

05

164.312(e) — Transmission Security

TLS termination at the edge with modern ciphers, current certificates and modern protocol versions. HSTS, OCSP stapling, optional mTLS. Internal backend legs can also be TLS-protected from the TR7 edge.

06

164.308(a)(4) — Information Access Management

AAM enforces per-application access policy at the application edge. Identity, device posture, geography, time-of-day and MFA strength feed access decisions. Workforce members reach only the clinical applications their role authorises.

07

164.308(a)(5)(ii)(C) — Log-in Monitoring

Access events are logged and reviewable in the centralized audit trail. Failed authentication attempts, MFA challenges and step-up outcomes are captured for investigation and trend analysis.

08

2024 NPRM — emerging mandatory controls (current alignment)

The HHS 2024-12-27 Notice of Proposed Rulemaking would make MFA, encryption in transit, network segmentation around ePHI, and several other controls explicitly mandatory rather than "addressable." TR7 already deploys these as core capabilities — customers planning for the final rule are already aligned on the application-edge controls.

09

Honest scope — what TR7 does not cover

TR7 is the application-edge layer of a HIPAA programme. It does not replace 164.310 Physical Safeguards, workforce training, security policies, risk analysis, business associate management, contingency planning, encryption at rest (storage layer), vulnerability scanning, penetration testing, asset inventory or patch management. These are complementary controls in a complete HIPAA programme.

Where this outcome shows up

Hospitals and integrated delivery networks

Patient portals, clinician access, EHR-fronted public services. TR7 places TLS, WAAP, MFA and PHI masking in front of every ePHI-facing application; vTenant separates clinical workloads from non-clinical infrastructure on the same platform.

Telehealth and remote-care platforms

Video, scheduling, clinical messaging and patient APIs. Edge TLS, WAAP on every API, MFA on every clinician account, centralized audit for 164.312(b) — without spreading the controls across four vendors.

EHR vendors and clinical SaaS providers

Business associates serving many covered entities. vTenant gives each covered-entity customer its own administrative and audit boundary on shared TR7 infrastructure. PHI masking and access controls apply per tenant; BAA evidence comes from one consistent operator surface.

Medical imaging (PACS) and lab data exchange

DICOM imagery, HL7 message flows, FTP-based lab data and TCP/UDP clinical instruments — non-HTTP traffic on the same platform as the HTTP WAAP. Clientless RDP/SSH for PACS administrator access without distributing native clients.

Multi-site clinic networks and regional health systems

Many clinical sites, one operator team. vTenant scales site isolation; QoS pools keep each site's traffic separate; route tables keep ePHI flows distinct. Site-level audit boundaries without one appliance per location.

Research, clinical trial and biobank platforms

ePHI for research with stricter least-privilege boundaries. AAM Per-Service Authentication with role-aware access policy; PHI masking on staff-facing dashboards and APIs; audit trail for IRB and sponsor obligations.

18 features

Features that implement this solution

Capabilities referenced by this solution — the technical pieces that compose the controls described above.

Anti-OCR Protection

TR7 ZeroLeak
AI-Era ProtectionData Leakage PreventionHIPAA Compliance

Server-rendered pages with pixel-level modifications — readable on screen for the user, nonsense to OCR engines and AI vision models when extracted as an image.

Healthcare· Financial Services· Government· Education

Clientless Application Portal

TR7 AAM
Zero Trust AccessModernize Legacy AppsHIPAA CompliancePCI DSS Compliance

Browser-only access to RDP, VNC, SSH, Kubernetes and legacy systems — with credential vault, recording, and watermark built in.

Financial Services· Government· Healthcare

Multi-Factor Authentication

TR7 AAM
Zero Trust AccessHIPAA CompliancePCI DSS Compliance

Three MFA methods, per-service policy, trusted-device shortcut — no third-party MFA cloud.

Financial Services· Government· Healthcare

Conditional Access Policy Engine

TR7 AAM
Zero Trust AccessHIPAA CompliancePCI DSS Compliance

One flow engine decides every authentication outcome — who can reach what, after which factor, under which context.

Financial Services· Government· Healthcare

Continuous Trust Evaluation

TR7 AAM
Zero Trust AccessBot ManagementHIPAA CompliancePCI DSS Compliance

Trust earned at login doesn't carry forever. Every session stays under evaluation, every step of the way.

Financial Services· Government· Healthcare

Additional Identity Provider Integrations

TR7 AAM
Zero Trust AccessHIPAA CompliancePCI DSS Compliance

Connect every identity source beyond SAML and OIDC to the same access and audit flow.

Financial Services· Government

Inline TLS Backend Inspection

TR7 WAAPTR7 ADC
Web Application & API ProtectionAPI SecurityPCI DSS ComplianceHIPAA Compliance

WAAP inspection, mTLS identity and data masking keep working even as traffic flows to backends over TLS.

Financial Services· Healthcare· Government

IP Masking and Normalization

TR7 ADC
Application Delivery & AccelerationPCI DSS ComplianceHIPAA ComplianceData Leakage Prevention

Mask IP for log privacy, reconstruct the correct client IP across proxy chains.

Financial Services· Healthcare· Government

Native IPFIX / NetFlow Export

TR7 ADCTR7 WAAP
PCI DSS ComplianceHIPAA ComplianceApplication Delivery & Acceleration

Move beyond L3/L4 — carry HTTP context into your flow records.

Financial Services· Government

SSL/TLS Acceleration

TR7 ADC
Application Delivery & AccelerationWeb Application & API ProtectionPCI DSS ComplianceHIPAA Compliance

Move TLS beyond file-based configuration — turn it into a per-service security profile, certificate lifecycle and post-quantum readiness layer.

TLS / mTLS Client-Cert Authentication

TR7 ADCTR7 AAM
Zero Trust AccessApplication Delivery & AccelerationPCI DSS ComplianceHIPAA ComplianceAPI Security

Lift the client certificate out of connection control and turn it into an identity object that drives traffic decisions.

Financial Services· Government· Healthcare

Route Table Management

TR7 ADC
Application Delivery & AccelerationPCI DSS ComplianceHIPAA Compliance

Every tenant in its own routing world — overlapping IPs, static + dynamic routing and gateway monitoring from one panel.

Sensitive Data Masking

TR7 WAAPTR7 ADC
API SecurityPCI DSS ComplianceHIPAA ComplianceData Leakage Prevention

Mask sensitive data at platform level before it reaches the user or the logs.

Healthcare· Financial Services· Government

SIEM Log Streaming

TR7 WAAPTR7 ADCTR7 AAM
PCI DSS ComplianceHIPAA Compliance

Send every platform event to your SIEM in the format it expects — JSON, CEF or plainText.

Financial Services· Government· Healthcare

vTenant Virtualization

TR7 vTenant
PCI DSS ComplianceHIPAA ComplianceModernize Legacy Apps

One TR7. Many tenants. Resources, network and operations boundaries each kept separate.

Financial Services· Healthcare· Government

Layer 7 Reporting Add-on

TR7 L7 Reporting
PCI DSS ComplianceHIPAA Compliance

Make every L7 request measurable, filterable and reportable.

Financial Services· Healthcare· Government

Advanced PDF Reporting

TR7 ADCTR7 WAAPTR7 AAM
PCI DSS ComplianceHIPAA Compliance

Produce branded, scheduled and on-demand PDF/XLSX reports in a single reporting pipeline.

Financial Services· Healthcare· Government

WAAP Compliance Reporting

TR7 WAAP
PCI DSS ComplianceHIPAA Compliance

Turn raw WAAP logs into readable evidence reports for auditors, management and customers.

Financial Services· Government· Healthcare

Common questions

Which HIPAA Security Rule requirements does TR7 cover at the application edge?
TR7 covers the application-edge portion of 164.312 Technical Safeguards — (a) Access Control, (b) Audit Controls, (d) Person/Entity Authentication, (e) Transmission Security, and a partial share of (c) Integrity on the wire. From 164.308 Administrative Safeguards, TR7 supports the application-edge portion of (a)(4) Information Access Management and (a)(5)(ii)(C) Log-in Monitoring. Other Administrative Safeguards (workforce training, risk analysis, contingency planning) and the entire 164.310 Physical Safeguards live outside TR7's scope.
Does deploying TR7 make our organisation HIPAA compliant?
No — and no product can. HIPAA compliance is a programme, not a product. What TR7 does is implement specific technical controls that map to the application-edge requirements of the Security Rule, on one platform, with audit artifacts that an assessor or breach investigator can review. The deployment is a substantial part of the application-edge control surface; the programme that surrounds it — policies, training, risk analysis, BAA management, contingency planning, physical controls — completes it.
What about the HHS 2024 Notice of Proposed Rulemaking on the Security Rule?
The HHS Office for Civil Rights issued the Notice of Proposed Rulemaking on 27 December 2024 to modernise the Security Rule. The proposed direction makes MFA, encryption in transit, network segmentation around ePHI and several other controls explicitly mandatory rather than "addressable." The comment period closed on 7 March 2025; the final rule is expected to take effect with a 180-day compliance period. TR7's application-edge stance already aligns with these proposals — customers preparing for the final rule are already covered on the controls that live at the application edge.
How does vTenant help multi-site healthcare organisations and BAA service providers?
Multi-site hospitals, regional health systems and clinical SaaS providers need per-site or per-customer isolation without one appliance per site. vTenant provides administrative, operational and observability isolation between tenants on shared TR7 infrastructure. An ePHI-scoped tenant runs alongside other tenants with its own vServices, policies, audit trail and operator boundary. For BAA service providers, each covered-entity customer can run in its own tenant; BAA-relevant evidence comes from one consistent operator surface.
Does ePHI leave our network when it passes through TR7?
No. TR7 runs on your hardware, in your data centre, under your network controls. The TLS termination, the WAAP inspection, the MFA decision, the PHI masking and the audit all happen on your network. No third-party cloud is in the path of ePHI. Because TR7 does not host or transmit your ePHI for you, the TR7 platform itself does not require a business associate agreement — it runs in your environment as your own infrastructure.
How does this compare to running HIPAA controls on a cloud WAAP?
On a cloud WAAP, ePHI transits the WAAP vendor's edge — and the vendor must sign a BAA, typically only available on enterprise tiers. Some organisations accept that scope; others need ePHI inspection to happen inside their own network for governance, data residency or regulator reasons. TR7's on-prem first model keeps that boundary inside your network without giving up the controls. The same six pillars (TLS, access, MFA, isolation, masking, audit) run on the same platform you already manage.
Is all of this on the same platform, or do we need separate modules?
Same platform. ADC, WAAP and AAM run on the same engine. No separate access module, no separate multi-tenancy add-on, no separate masking SKU, no separate audit add-on — all included under the same bandwidth license. The pricing model is the bandwidth your clinical applications actually serve — predictable and aligned to the value moving through the platform.
What does TR7 not cover for HIPAA?
Honest list: 164.310 Physical Safeguards (facility, workstation, device); workforce training, security policies, risk analysis, business associate management and contingency planning under 164.308; encryption at rest (storage layer); vulnerability scanning and penetration testing (called out in the 2024 NPRM); asset inventory and patch management; endpoint device management. TR7 is the application-edge layer of a HIPAA programme — these are complementary controls a complete programme needs alongside it.

HIPAA Security Rule — on one TR7 platform, on your own network

Bring your HIPAA scope to a TR7 demo. We will walk through TLS at the edge, WAAP in front of clinical applications, MFA for every account reaching ePHI, vTenant isolation between clinical and non-clinical workloads, PHI masking and the audit trail — exactly the artifacts an assessor or breach investigator asks for.