In the enterprise, protocol selection is often not driven by 'best practice,' but by 'compliance.' Regulations dictate the minimum strength of encryption and the specific types of authentication that must be used.
Each regulatory framework has a different 'Threat Model.' PCI DSS focuses on credit card data, HIPAA on health records, and FedRAMP on US Government cloud security.
Compliance is not the same as Security. You can be compliant and still be hacked, but if you are non-compliant, you face massive fines and legal liability.
| Standard | Focus | Key Protocol Requirement | Penalty |
|---|---|---|---|
| PCI DSS | Payment Cards | Strong Encryption (TLS 1.2+), No WEP/WPA | Fines / Loss of Merchant Status |
| HIPAA | Healthcare Data | Encryption in transit and at rest | Civil/Criminal Penalties |
| FedRAMP | Gov Cloud | FIPS 140-2 Validated Modules | Loss of Gov Contract |
| NIST 800-63 | Digital Identity | AAL (Authenticator Assurance Levels) | Audit Failure |
For example, if a company handles credit cards, PCI DSS explicitly forbids the use of SSLv2, SSLv3, and early TLS versions, forcing the company to upgrade their protocol stack regardless of the cost.
💡 NIST 800-63 defines 'Assurance Levels' (AAL). AAL1 might only require a password, while AAL3 requires a hardware-based cryptographic authenticator (like a Yubikey).
compliance_check:
standard: NIST_800_63
level: AAL3
requirements:
- MFA: "Mandatory"
- Hardware_Token: "Required"
- Session_Timeout: "15min"
- Encryption: "FIPS-Validated"When an enterprise selects a protocol (like SAML or OIDC), they must map it to these levels. If they claim AAL3 compliance, they cannot allow 'Password-only' authentication.
Compliance is a snapshot in time. A protocol that was 'compliant' in 2022 (like TLS 1.1) may be 'non-compliant' in 2025.
The most dangerous mistake is assuming that a 'Certified' product is secure. Certification only means the product *can* be secure if configured correctly.
Verify exercises to earn ★ 180 XP and unlock next lab level.