Cryptographic Protections Standard

Organization: FrontRunnerHC, Inc. (FRHC)
Parent Policy Reference: Summit Technology Holdings – Cryptographic Protections Policy
Framework Reference: Secure Controls Framework – Cryptographic Protections (CRY)

1. Purpose

This standard defines how FrontRunnerHC (FRHC) implements the enterprise-wide cryptographic requirements established by Summit Technology Holdings, LLC (STH). It documents the operational use of encryption, key management, and secure communication mechanisms used to protect the confidentiality, integrity, and availability of sensitive and regulated data—including ePHI—across FRHC’s Azure, AWS, and Microsoft 365 environments.

2. Applicability

This standard applies to all FRHC systems, applications, endpoints, cloud environments, storage platforms, and communication channels where sensitive or regulated data is stored, processed, or transmitted. It extends to third-party services operating under Business Associate Agreements (BAAs) with FRHC where cryptographic controls are relevant.

3. Standard

3.1 Use of Cryptographic Controls

FRHC implements cryptographic protections using industry-accepted algorithms and protocols across all systems and platforms. At minimum, FRHC adheres to the following baselines established by STH:

AES-256 for data at rest
TLS 1.2 or higher for data in transit
FIPS 140-2/3 validated cryptographic modules where available
Deprecated algorithms (e.g., MD5, SHA-1, DES, RC4) are prohibited

Cryptographic controls are applied consistently across Azure, AWS, and Microsoft 365 environments, leveraging platform-native encryption capabilities where appropriate.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.1
SCF Mapping: CRY-01 (Use of Cryptographic Controls)

3.2 Transmission Confidentiality

FRHC encrypts sensitive data during transmission across internal networks, external connections, APIs, and partner integrations. TLS 1.2 or higher is enforced for all web services, APIs, and application-layer communications. Microsoft 365 is configured with enforced TLS and message encryption for sensitive email communications. VPN-protected channels with strong cipher suites are required for remote access.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.2
SCF Mapping: CRY-03 (Transmission Confidentiality)

3.3 Transmission Integrity

Cryptographic mechanisms are used to ensure the integrity of data transmitted across FRHC networks. Secure transport protocols provide built-in integrity validation to prevent unauthorized modification or tampering during transmission. FRHC’s use of TLS for all sensitive data channels provides this protection by default.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.2
SCF Mapping: CRY-04 (Transmission Integrity)

3.4 Encrypting Data at Rest

FRHC encrypts sensitive data at rest across Azure storage services, AWS storage resources, databases, application data stores, backups, and endpoint devices. Azure Storage Service Encryption and AWS server-side encryption are enabled for all FRHC-managed storage. Database encryption (Transparent Data Encryption or equivalent) is applied to databases containing ePHI or other regulated data. Endpoint devices are enrolled in Microsoft Intune with BitLocker encryption enforced via compliance policy.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.3
SCF Mapping: CRY-05 (Encrypting Data At Rest)

3.5 Non-Console Administrative Access

All administrative access to FRHC systems is conducted over encrypted channels. SSH, HTTPS, and RDP over TLS are required for remote administration. Legacy cleartext protocols (e.g., Telnet, FTP) are prohibited. VPN-based access with strong encryption is required for administrative connections to infrastructure not exposed through secured management planes. These controls are enforced through FRHC’s network security and Conditional Access configurations.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.4
SCF Mapping: CRY-06 (Non-Console Administrative Access)

3.6 Wireless Access Authentication & Encryption

FRHC secures corporate wireless networks using WPA2 or WPA3 security protocols with encryption enabled for all authorized connections. Wireless access is restricted to authorized users and devices. Guest networks, where present, are logically segmented from internal systems and resources. Sensitive data is not transmitted over unsecured or open wireless networks.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.5
SCF Mapping: CRY-07 (Wireless Access Authentication & Encryption)

3.7 Public Key Infrastructure (PKI)

FRHC uses trusted digital certificates issued by reputable public certificate authorities for external-facing services. Certificate inventories are maintained and monitored to prevent expiration-related outages. Certificates are revoked promptly if compromised. Self-signed certificates are not used in production environments. Azure Key Vault is used to centralize certificate management where applicable.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.6
SCF Mapping: CRY-08 (Public Key Infrastructure (PKI))

3.8 Cryptographic Key Management

FRHC manages cryptographic keys using Azure Key Vault and AWS KMS as enterprise-approved key management solutions. Key lifecycle activities include secure generation, access-controlled storage, periodic rotation, and secure destruction when keys are retired or compromised. Key access is restricted using least-privilege principles, and all key operations are logged for audit purposes. Keys are rotated at least annually or immediately upon suspected compromise.

Parent Policy Mapping: STH Cryptographic Protections Policy, Section 3.7
SCF Mapping: CRY-09 (Cryptographic Key Management)

4. Compliance & Governance

FRHC maintains evidence of cryptographic control implementation, including encryption configurations, certificate inventories, key rotation records, and access controls. IT Security reviews cryptographic configurations at least annually and after significant changes to FRHC’s technology environment. Evidence is retained to support SOC 2 Type II audits and HIPAA Security Rule compliance assessments.

5. Enforcement

All users (employees, contractors, part-time and temporary workers) and those employed by others to perform work for the organization, or who have been granted access to IT assets or facilities, are covered by this standard and must comply with its associated policies, procedures, standards and guidelines.

Failure to comply with this standard and associated guidelines may result in suspension of use privileges or other disciplinary actions up to and including termination and/or legal action.

6. References

Parent Policy:

Summit Technology Holdings – Cryptographic Protections Policy

Regulatory Requirements:

HIPAA Security Rule:
- 45 CFR §164.312(a)(2)(iv) – Encryption and Decryption
- 45 CFR §164.312(e)(1) – Transmission Security
AICPA SOC 2 Trust Services Criteria:
- Security (CC6, CC7)
- Confidentiality (C1)
New York SHIELD Act: GBL §899-bb(2)(b)(ii) (Technical Safeguards — Encryption of Data in Transit and at Rest)
Nevada NRS 603A.215 (Encryption Required for Electronic Transmission of PI Outside Secure System and for Data Storage Devices Moved Outside Logical/Physical Controls)

Framework Alignment:

CRY-01 – Use of Cryptographic Controls
CRY-03 – Transmission Confidentiality
CRY-04 – Transmission Integrity
CRY-05 – Encrypting Data At Rest
CRY-06 – Non-Console Administrative Access
CRY-07 – Wireless Access Authentication & Encryption
CRY-08 – Public Key Infrastructure (PKI)
CRY-09 – Cryptographic Key Management

7. Revision Tracking

Rev	Description	Date	Approved
-	Policy created	July 2021	M Machin
1.0	Formatting Update	September 2022	WSI
2.0	Updated and approved for 2024	July 2024	WSI
3.0	Updated and approved for 2025	July 2025	M Machin
4.0	Converted to Standard	April 2026	M Machin
4.1	Added NY SHIELD Act and Nevada NRS 603A.215 citations	April 2026	M Machin

Internal Use Only