Hands-On Quantum-Safe PKI: A Practical Post-Quantum Cryptography Implementation Guide
Updated 01.16.26 for FrodoKEM/BIKE/HQC alternate algorithms Is your Public Key Infrastructure quantum-ready? Remember way back when we built the PQC CNSA 2.0 Implementation guide in October 2025? So long ago! Due to popular request, we've expanded the lab to now include THREE distinct learning paths: NIST FIPS standards, NSA CNSA 2.0 compliance, AND alternative post-quantum algorithms for those wanting diversity or international compliance options.. The GitHub lab guide walks you through building quantum-resistant certificate authorities using OpenSSL with hands-on exercises. Why learn and implement post-quantum cryptography (PQC) now? While quantum computing is a fascinating area of science, all technological advancements can be misused. Nefarious people and nation-states are extracting encrypted data to decrypt at a later date when quantum computers become available, a practice you better know by now called "harvest now, decrypt later." Close your post-quantum cryptographic knowledge gap so you can get secured sooner and reduce the impact(s) that may not surface until after it's too late. Ignorance is not bliss when it comes to cryptography and regulatory fines, so let's get started. The GitHub lab provides step-by-step instructions to create: Quantum-resistant Root CA using ML-DSA-87 (FIPS and CNSA 2.0) Algorithm flexibility based on your compliance needs Quantum-safe server and client certificates OCSP and CRL revocation for quantum-resistant certificates TLS 1.3 key exchange testing with ML-KEM and hybrid modes Alternative algorithm exploration (FrodoKEM, BIKE, HQC) for TLS/KEM usage Access the Complete Lab Guide on GitHub → At A Glance: OpenSSL Quantum-Resistant CA Learning Paths Select the path that aligns with your requirements: FIPS 203/204/205 CNSA 2.0 Alt. Algorithms Target Audience Commercial organizations Government contractors, classified systems Researchers, international compliance, defense-in-depth Compliance Standard NIST FIPS standards NSA CNSA 2.0 Non-NIST algorithms, international standards Algorithm Coverage ML-DSA, ML-KEM, SLH-DSA, Hybrid ML-DSA-65/87, ML-KEM-768/1024 FrodoKEM, BIKE, HQC Use Case General quantum-resistant infrastructure National security systems Algorithm diversity, conservative security 📚 Learning Path 1: NIST FIPS 203/204/205 For commercial organizations implementing quantum-resistant cryptography using NIST standards. This path uses OpenSSL 3.5.x's native post-quantum cryptography support—no external quantum library providers required. So nice, so easy. Modules Module Description 00 - Introduction Overview of FIPS 203/204/205, prerequisites, and lab objectives 01 - Environment Setup Verifying OpenSSL with PQC support 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-65 04 - Certificates Issuing end-entity certificates for servers and users 05 - Revocation Implementing OCSP and CRL certificate revocation 06 - Hybrid Methods IETF hybrid PQC methods (X25519MLKEM768, composite signatures) Algorithms Covered ML-DSA-44/65/87 (FIPS 204) - Lattice-based signatures ML-KEM-512/768/1024 (FIPS 203) - Lattice-based key encapsulation X25519MLKEM768 - Hybrid TLS 1.3 key exchange 📚 Learning Path 2: NSA CNSA 2.0 For government contractors and organizations requiring CNSA 2.0 compliance. This path uses OpenSSL 3.2+ with Open Quantum Safe (OQS) providers for strict CNSA 2.0 algorithm compliance. Modules Module Description 01 - Introduction Overview of CNSA 2.0 requirements and compliance deadlines 02 - Root CA Building a Root CA with ML-DSA-87 03 - Intermediate CA Creating an Intermediate CA with ML-DSA-65 04 - Certificates Issuing CNSA 2.0 compliant certificates 05 - Revocation Implementing OCSP and CRL certificate revocation CNSA 2.0 Approved Algorithms Algorithm Type Approved Algorithms NIST Designation Digital Signatures ML-DSA-65, ML-DSA-87 FIPS 204 Key Establishment ML-KEM-768, ML-KEM-1024 FIPS 203 Hash Functions SHA-384, SHA-512 FIPS 180-4 Note: CNSA 2.0 currently does NOT support ML-DSA-44, SLH-DSA, or Falcon algorithms. 📚 Learning Path 3: Alternative PQC Algorithms (NEW!) For researchers, organizations requiring algorithm diversity, and those interested in international PQC implementations. This path explores post-quantum algorithms outside the primary NIST standards, providing options for defense-in-depth strategies and understanding of the broader PQC landscape. Perfect for organizations wanting to hedge against potential future vulnerabilities in current adopted standards. Modules Module Description 00 - Introduction Overview of non-NIST algorithms, international standards, use cases 01 - Environment Setup OpenSSL and modifying OQS provider configuration 02 - FrodoKEM Conservative unstructured lattice KEM (European recommended: BSI, ANSSI) 03 - BIKE and HQC Code-based KEMs (HQC is NIST-selected backup to ML-KEM) 04 - International PQC EU, South Korean, and Chinese algorithm standards 05 - Performance Analysis Comparing algorithms, latency impacts, use cases, nerd stats Algorithms Covered Algorithm Type Mathematical Basis Key Characteristic FrodoKEM KEM Unstructured lattice (LWE) Conservative security, European endorsed (BSI, ANSSI) BIKE KEM Code-based (QC-MDPC) NIST Round 4 candidate, smaller keys than HQC HQC KEM Code-based (Quasi-cyclic) NIST-selected backup to ML-KEM (standard expected 2027) Why Alternative Algorithms Matter Algorithm Diversity: If a vulnerability is found in lattice-based cryptography (ML-KEM), code-based alternatives provide a backup International Compliance: European agencies (BSI, ANSSI) specifically recommend FrodoKEM for conservative security Future-Proofing: HQC will become a FIPS standard in 2027 as NIST's official backup to ML-KEM Research & Testing: Understand the broader PQC landscape for informed decision-making What This Lab Guide Achieves Complete PKI Hierarchy Implementation The lab walks through building an internal PKI infrastructure from scratch, including: Root Certificate Authority: Using ML-DSA-87 providing the highest quantum-ready NIST security level Intermediate Certificate Authority: Intermediate CA using ML-DSA-65 for operational certificate issuance End-Entity Certificates: Server and user certificates with comprehensive Subject Alternative Names (SANs) for real-world applications Revocation Infrastructure: Both Certificate Revocation Lists (CRL) and Online Certificate Status Protocol (OCSP) implementation TLS 1.3 Key Exchange Testing: Hands-on testing with ML-KEM, hybrid modes, and alternative algorithms Security Best Practices: Restrictive Unix file permissions, secure key storage, and backup procedures throughout Key Takeaways After completing one or more of the labs, you will: Understand ML-DSA Cryptography: Gain hands-on experience with both ML-DSA-65 (Level 3 security) and ML-DSA-87 (Level 5 security) algorithms Explore Algorithm Diversity: Understand when and why to use alternative algorithms like FrodoKEM, BIKE, and HQC Configure Modern PKI Features: Implement SANs with DNS, IP, email, and URI entries, plus both CRL and OCSP revocation mechanisms Test TLS 1.3 Key Exchange: Hands-on experience with ML-KEM and hybrid key exchange in real TLS sessions Troubleshoot Effectively: Learn to diagnose and resolve common issues with opensl and oqsproviders for PQC compatibility Prepare for Migration: Start the practical steps needed to transition existing PKI infrastructure to quantum-resistant algorithms Access the Complete Lab Guide on GitHub → About This Guide We built the first guide for NSA Suite B in the distant past (2017) to learn ECC and modern cipher requirements. It was well received enough to built a new guide for CNSA 2.0 but it's quite specific for US federal audiences. That lead us to build a NIST FIPS PQC guide which should apply to more practical use cases. And now we've added alternative algorithms because things are only going to get a bit more complicated moving forward. In the spirit of Learn Python the Hard Way, it focuses on manual repetition, hands-on interactions and real-world scenarios. It provides the practical experiences needed to implement quantum-resistant PKI in production environments. By building it on GitHub, other PKI fans can help where we may have missed something; or simply to expand on it with additional modules or forks. Have at it! Frequently Asked Questions (FAQs) Q: What is CNSA 2.0? A: CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA's updated cryptographic standard requiring quantum-resistant algorithms. Q: When do I need to implement quantum-resistant cryptography? A: The NSA and NIST mandate CNSA 2.0 and FIPS 203/204/205 implementation by 2030. Organizations should begin now due to "harvest now, decrypt later" attacks where adversaries collect encrypted data today for future quantum decryption. Q: What is ML-DSA (Dilithium)? A: ML-DSA (Module-Lattice Digital Signature Algorithm), formerly known as Dilithium, is a NIST-standardized quantum-resistant digital signature algorithm specified in FIPS 204. Q: What is ML-KEM (Kyber)? A: ML-KEM (Module-Lattice Key Encapsulation Mechanism), formerly known as Kyber, is a NIST-standardized quantum-resistant key encapsulation mechanism specified in FIPS 203. ML-KEM-768 provides roughly AES-192 equivalent security. Q: What are the alternative algorithms and why should I care? A: FrodoKEM, BIKE, and HQC are non-NIST-primary algorithms that provide algorithm diversity. If a vulnerability is discovered in lattice-based cryptography (which ML-KEM and ML-DSA use), code-based alternatives like HQC could provide a backup. HQC is actually NIST's selected backup to ML-KEM and will become a FIPS standard in 2027. Q: What's the difference between BIKE and HQC? A: Both are code-based KEMs. BIKE has smaller key sizes but wasn't selected by NIST. HQC has larger keys and was selected as NIST's official backup to ML-KEM. Q: Why do European agencies recommend FrodoKEM? A: FrodoKEM uses unstructured lattices (standard LWE) rather than the structured lattices used in ML-KEM. This provides more conservative security assumptions at the cost of larger key sizes. Germany's BSI and France's ANSSI specifically recommend FrodoKEM for high-security applications. Q: Is this guide suitable for production use? A: NOPE. While the guide teaches production-ready techniques and compliance requirements, always use Hardware Security Modules (HSMs) and air-gapped systems for production Root CAs (cold storage too). The lab is great for internal environments or test harnesses where you may need to test against new quantum-resistant signatures. ALWAYS rely on trusted public PKI infrastructure for production cryptography. 🤓 Happy PKI'ing! Reference Links NIST Post-Quantum Cryptography Standards - Official NIST PQC project page FIPS 203: ML-KEM Standard - Module-Lattice Key Encapsulation Mechanism FIPS 204: ML-DSA Standard - Module-Lattice Digital Signature Algorithm FIPS 205: SLH-DSA Standard - Stateless Hash-Based Digital Signature Algorithm NSA CNSA 2.0 Algorithm Requirements - NSA's official CNSA 2.0 announcement Open Quantum Safe Project - Home of the OQS provider for alternative algorithms OQS Provider for OpenSSL 3 - GitHub repository for OQS provider HQC Specification - Official HQC algorithm documentation BIKE Specification - Official BIKE algorithm documentation OpenSSL 3.5 Documentation - Comprehensive OpenSSL documentationBreaking Down the Quantum Challenge: Why Post-Quantum Cryptography Can't Wait
The Quantum Challenge is Now Post-quantum cryptography represents the next steps of our digital security evolution. Sure, quantum systems capable of breaking current encryption may still be an a few years away, but those beginning their transition now will be well-positioned for when the crypto hits the fan. Nation-state adversaries and sophisticated private entities may be collecting data today hoping to decrypt it tomorrow so it's never to early to start solving the problem now. It's an excellent time to get ahead of the curve with quantum-resistant cryptography. What does this mean for your organization? Any sensitive data encrypted today using standard methods (RSA, ECDSA) could potentially become readable to future quantum-powered attackers. F5 Community Evangelist Chase Abbott discusses the real world implications of quantum computing, and how you can prepare and migrate to NIST-approved hybrid PQC standards. The transition to post-quantum cryptography represents a perfect opportunity to modernize enterprise PKI practices. Those of you that begin planning today have ample time to implement these changes thoughtfully and strategically, positioning yourselves as leaders in the next generation of cybersecurity; high fives all around. The Business Impact: Beyond Technical Considerations Regulatory and Compliance Pressure Government regulations across the globe are creating concrete deadlines for migration strategies: NSA CNSA 2.0 mandates quantum-resistant algorithms for classified systems by 2030 NIST has standardized post-quantum cryptography algorithms (FIPS 203, 204, 205) Industry regulations in finance, healthcare, and defense are beginning to incorporate quantum-safety requirements adhering to the update FIPS governance Your Quantum-Ready Roadmap: A Manageable Transition Phase 1: Assessment and Inventory Action items for leadership: Conduct cryptographic inventory across all systems and applications Identify critical data requiring long-term protection Assess vendor and third-party quantum readiness Establish quantum cryptography governance and budget allocation Phase 2: Pilot Implementation Strategic focus areas: Deploy quantum-resistant algorithms in non-critical environments Train IT and security teams on post-quantum cryptography Establish partnerships with quantum-ready technology vendors Begin updating security policies and procedures Phase 3: Production Migration Enterprise-wide deployment: Implement hybrid classical/quantum-resistant systems and software Migrate critical applications and PKI aggregation points to quantum-safe algorithms Update business continuity and disaster recovery plans Achieve full compliance with regulatory requirements as a priority over other systems Key Takeaways for Business Leaders Start planning now: The quantum threat timeline is uncertain, but the need for preparation is immediate Prioritize critical assets: Focus initial efforts on protecting your most sensitive and long-lived data Invest in capabilities: Quantum cryptography expertise will become as essential as any other IT security skill Engage stakeholders: Quantum security requires coordination across IT, compliance, procurement, and business units Monitor developments: Stay informed about quantum computing advances and regulatory updates Mahalo! Further Reading: Post Quantum Cryptography Coalition: PQC Migration Roadmap Post Quantum Cryptography Coalition: International PQC Requirements Post Quantum Cryptography Coalition: Inventory Workbook Essence of Linear Algebra Quantum Computing for the Very Curious Looking Glass Universe: Why I Left Quantum Computing Research US National Quantum Initiative
F5's API Security Alignment with NIST SP 800-228
Introduction F5 has positioned itself as a comprehensive API security leader with solutions that directly address the emerging NIST SP 800-228 "Guidelines for API Protection for Cloud-Native Systems."F5’s multi-layered approach covers the entire API lifecycle, from development to runtime protection. It is closely aligned with NIST’s recommended controls and architectural patterns. F5's product portfolio comprehensively addresses NIST 800-228 requirements F5's current API security ecosystem includes BIG-IP Advanced WAFF5 Distributed Cloud Services, and NGINX Plus . This creates a unified platform that addresses all 22 NIST recommended controls (REC-API-1 through REC-API-22). The company's 2024 acquisition of Wib Security strengthened its pre-runtime protection capabilities, while Heyhack enhanced its penetration testing offerings. These strategic moves demonstrate F5's commitment to comprehensive API security coverage. The F5 Distributed Cloud Services API Security platform is a comprehensive WAAP solution. The platform provides AI-powered API discovery, real-time threat detection, advanced bot protection, web application firewall, DoS/DDoS protection, and automated policy enforcement. This directly supports NIST's focus on continuous monitoring and adaptive security. Comprehensive mapping to NIST SP 800-228 control framework F5's solutions address all seven thematic groups outlined in NIST SP 800-228. These "target" objectives include security controls that address the OWASP API Top 10. These mitigations address broken object-level authentication, sensitive information disclosure, input validation, and other security vulnerabilities. If you haven't read the new document, I encourage you to do so. You can find the document here. The following may seem confusing at first, but the REC-API headings map to the NIST document. These are high-level target controls. You can further group these by thinking of Pre-Runtime Protections (REC-API-1 through REC-API-8) and Runtime Protections (REC-API-9 through REC-API-22). We have done our best to map F5's capabilities at a high level to the target controls below. In a future article, we will provide specific configuration controls mapping to each target level. API specification and inventory management (REC-API-1 to REC-API-4) F5's AI/ML-powered API discovery automatically identifies and catalogs API endpoints, including shadow APIs that pose security risks. The platform generates OpenAPI specifications from traffic analysis and maintains a real-time API inventory with risk scoring. The F5 Distributed Cloud Services platform provides external domain crawling and comprehensive API lifecycle tracking. This directly addressing NIST's requirements for preventing unauthorized APIs from becoming attack vectors. API Discovery of API Endpoints Schema validation and input handling (REC-API-5 to REC-API-8) F5 implements a positive security model that enforces OpenAPI specifications at runtime. F5 platforms provide granular parameter validation, content-type enforcement, and request size limiting. The platform automatically validates request/response schemas against predefined specifications and uses machine learning to detect schema drift, ensuring continuous compliance with API contracts. In cases when a pre-defined schema is not available, the platform can "learn" through discovery and build an Open API Spec that can later be imported into the platform for adding security controls. Authentication and authorization (REC-API-9 to REC-API-12) F5's authentication architecture supports OAuth 2.0, OpenID Connect, SAML, and JWT validation with comprehensive scope checking. The F5 Application Delivery and Security platform provides per-request policy enforcement with role-based access control (RBAC) and attribute-based access control (ABAC). The platform's cryptographic X.509 identity bootstrapping ensures every component receives unique identity credentials, supporting NIST's emphasis on strong authentication mechanisms. Sensitive data protection (REC-API-13 to REC-API-15) F5's data classification engine automatically identifies and protects PII, HIPAA, GDPR, and PCI-DSS data types flowing through APIs. The platform implements real-time data flow policies with redaction mechanisms and monitors for potential data exfiltration. The F5 Distributed Cloud Services provides context-aware data protection that goes beyond traditional PII to include business-sensitive information. Sensitive Information Discovery and Redaction Access control and request flow (REC-API-16 to REC-API-18) F5's real-time response capabilities enable immediate blocking of specific keys or users on demand. The platform implements mature token management with hardened API behavior detection for abnormal usage patterns. The behavioral analytics engine continuously monitors API usage patterns to detect compromised credentials and automated attacks. Rate limiting and abuse prevention (REC-API-19 to REC-API-21) F5 provides granular rate limiting by user, IP, application ID, method, and field through multiple implementation approaches. The NGINX Plus leaky bucket algorithm ensures smooth traffic management, while BIG-IP APM offers sophisticated quota management with spike arrest capabilities. The platform's L7 DDoS protection uses machine learning to detect and mitigate application-layer attacks accurately. API Endpoint Rate Limiting Settings Logging and observability (REC-API-22) F5's comprehensive logging framework captures all API interactions, authentication events, and data access with contextual information. The platform provides real-time analytics with application performance monitoring, security event correlation, and business intelligence capabilities. Integration with SIEM platforms like Splunk and Datadog ensures actionable intelligence connects to operational response capabilities. Implementation of NIST's three API gateway patterns F5's architecture uniquely supports all three API gateway patterns outlined in NIST SP 800-228: Centralized gateway pattern The F5 Distributed Cloud ADN provides a global application delivery network with centralized policy management through a unified SaaS console. This approach ensures consistent security policy enforcement across all endpoints while leveraging F5's global network infrastructure for optimal performance and threat intelligence sharing. Hybrid gateway pattern F5's distributed data plane with centralized control represents the optimal balance between centralized management and distributed performance. The F5 Distributed Customer Edge nodes deployed at customer sites provide local API processing with global policy synchronization. This enables organizations to maintain data sovereignty while benefiting from centralized security management. Decentralized gateway pattern The NGINX Plus deployment model enables lightweight API gateways positioned close to applications, perfect for microservices architectures. The NGINX Ingress Controller provides Kubernetes-native API management with per-service gateway deployment in service mesh environments. This ensures policy enforcement occurs as close to individual service instances as possible. In addition, BIG-IP can be deployed to provide API security and provide many of the same mitigations as listed above. This can be beneficial as most modern enterprises already have F5 BIG-IPs in their environments. Advanced zero trust and identity-based segmentation F5's zero trust architecture implements NIST's identity-centric security principles through cryptographic principles. TLS is a cornerstone of F5 technologies. Our platforms are purpose-built for cryptography, including TLS 1.3 and Post Quantum. mTLS can be used to authenticate both sides of the TLS handshake. F5's strong authentication and authorization features fit nicely into an API Security Zero Trust design. The continuous verification model ensures no implicit trust based on network location, while least privilege enforcement provides granular access control based on identity and attributes. F5's integration with enterprise identity providers like Microsoft Entra ID and Okta enables seamless implementation of zero trust principles across existing infrastructure. Comprehensive pre-runtime and runtime protection F5's pre-runtime protection includes integration with CI/CD pipelines through the recent Wib Security acquisition, enabling vulnerability detection during development. The platform provides automated security reconnaissance through Heyhack's capabilities and API scanning before production deployment. For runtime protection, F5's behavioral analytics engine establishes baseline API behavior and detects anomalies in real-time. The threat intelligence integration protects coordinated attack campaigns. API endpoint markup automatically identifies and tokenizes dynamic URL components for enhanced protection. Implementation recommendations Organizations implementing F5 solutions for NIST SP 800-228 compliance should consider a phased approach starting with API discovery and inventory management, followed by authentication and authorization controls, and culminating in comprehensive monitoring and analytics. For a purely SaaS solution, Distributed Cloud presents a mature API security solution offering cutting-edge capabilities. For enterprises requiring on-premises deployment, BIG-IP Advanced WAF and Access Policy Manager provide the most robust capabilities with enterprise-grade performance and extensive customization options. The hybrid deployment model of SaaS and on-premises often provides the optimal balance of cost, performance, and security for large organizations with complex infrastructure requirements. Conclusion F5's API security portfolio represents a mature, comprehensive solution that directly addresses the full spectrum of NIST SP 800-228 requirements. F5’s strategic acquisitions, innovative AI integration, and proven enterprise scalability position it as a leading choice for organizations seeking to implement comprehensive API security aligned with emerging federal guidelines. With continued investment in cloud-native capabilities and AI-powered threat detection, F5 is well-positioned to maintain its leadership as API security requirements continue evolving.Zero Trust Application Access for Federal Agencies
Introduction Zero Trust Network Access (ZTNA) and Zero Trust Application Access (ZTAA) represent two distinct architectural approaches to implementing zero trust application access. ZTAA is emerging as the superior choice for enterprises seeking high-performance, application-centric protection. While both operate under the "never trust, always verify" principle, ZTAA can deliver better performance, lower costs, and provide greater granular control at the application layer, where business-critical assets reside. As a leader in application access, F5 provides strong authentication and authorization through its mature BIG-IP Access Policy Manager platform. Access Policy Manager, or APM, is a tool that helps organizations with zero trust. It does this by following many of the zero trust principles that organizations like the DoD, CISA, and NIST document. Capabilities like strong encryption, user interrogation, conditional and contextual access, device posture, risk scoring, and API integration with third-party security vendors all contribute to a modern zero-trust access solution. It can be said that F5 and APM were the original zero-trust access solutions long before Forrester coined the term "zero trust" back in 2010. Understanding the Architectural Divide ZTNA operates as a network-centric model, creating secure tunnels from users to applications through centralized trust brokers and gateways. This approach can necessitate substantial modifications to the network infrastructure, client software deployment, and, in some cases, re-routing all traffic through tunnel concentration points. ZTNA is well-established and has well-established vendor ecosystems. However, ZTNA can cause performance problems, increase latency, and require big changes to the network architecture. Zero Trust Application Access is different because it focuses on individual applications. It protects these applications directly by using reverse proxies that are already in place in the business environments where these applications are located or at cloud gateways for cloud-based workloads. This architecture lets users connect directly to applications without tunneling. This means no extra work, keeps existing network investments, and gives you control at the application layer. ZTAA operates agentless in many scenarios and integrates seamlessly with cloud-native, containerized, and microservices architectures. F5 Zero Trust Direct Application Access The technical differences create distinct performance profiles. ZTNA's tunnel concentration can create bottlenecks for high-volume applications and add latency from traffic backhauling. At the same time, ZTAA eliminates these performance issues through direct application access and a distributed proxy architecture. Organizations with large application portfolios, cloud-native environments, or performance-sensitive applications find that ZTAA delivers superior user experience and operational efficiency. It is worth noting that ZTNA solutions are, at their core, just a proxy and use encryption for transport, such as TLS or IPsec. ZTAA or ZTNA? Application portfolio size serves as a strong decision criterion. Cost and complexity are also strong considerations. Organizations with fewer than 20 applications, primarily legacy systems, and uniform user bases typically find ZTNA's network-centric approach adequate. However, enterprises with 20+ applications, cloud-native architectures, and diverse user requirements achieve better outcomes with ZTAA's application-specific controls. Performance requirements strongly favor ZTAA for high-volume, real-time, or latency-sensitive applications. Cost considerations also help ZTAA adoption. It can be implemented for a smaller amount of ZTNA costs (depending on how the vendor is doing it) while keeping current network infrastructure investments. Organizations prioritizing rapid deployment, application-by-application rollout, or cloud-first strategies find ZTAA's minimal infrastructure impact and flexible deployment models advantageous. Infrastructure strategy alignment matters significantly. ZTNA is best for big network changes and unified SASE plans. ZTAA is best for applications-first approaches, DevOps cultures, and cloud-native changes. The regulatory environment influences decisions, with some compliance frameworks requiring network-level controls that favor ZTNA, while others benefit from ZTAA's granular application-level security audit trails. F5's ZTAA Leadership Position for Federal Agencies F5 has a strong security position in both federal and commercial landscapes—nearly all the Fortune 50 trust F5 to protect their most mission-critical applications. In addition, federal organizations like the DoD and civilian agencies trust F5 to preserve our nation's most critical infrastructure. The federal sector was an early adopter of zero trust principles. NIST and CISA were instrumental in designing zero-trust reference architectures. The NIST 800-207 document was a landmark, describing how organizations can approach the implementation of a zero-trust architecture in their environments. The DoD Zero Trust Strategy document builds off this architecture and gets specific by calling out controls under each zero trust pillar. The DoD Zero Trust Strategy document outlines 152 targets and requirements for achieving a mature zero trust implementation. F5 today meets or partially meets 57 of those targets. In addition, recent work was published by the NCOEE/NIST describing a completely independent, tested solution utilizing F5 as a Zero Trust Application Access. CISA 5 Pillar Maturity Model – Optimal Level F5 Key Capabilities for Zero Trust Application Access F5 BIG-IP APM Identity Aware Proxy (ZTAA) uses access control per request that checks each application access attempt individually. This moves from session-based authentication to transaction-level verification. The platform provides context-aware authentication, evaluating user identity, device posture, location, and application sensitivity for each request. Continuous device posture checking maintains real-time, ongoing assessments throughout user sessions with adaptive multi-factor authentication and risk-based step-up authentication. F5's Privileged User Access (PUA) solution complements ZTAA with DoD-approved capabilities for both privileged and unprivileged user authentication to government systems. The agent-free deployment adds strong authentication, including CAC/PKI and MFA, to old systems that don’t have native support. It also manages temporary passwords and has many audit trails to make sure the system is compliant and secure. The solution is truly zero trust, with neither the end user nor the endpoint knowing the ephemeral password used during the session. Passwords are never stored on disk and are destroyed when the session terminates, creating a strong access solution. Full proxy architecture brings visibility into your network data plane. Protocols like TLS 1.3 and Post-Quantum look to strengthen your network security posture, but they also bring potential blind spots. TLS 1.3 key structure is ephemeral by design. This protocol feature is excellent for application security, but it creates potential blind spots for threat hunters. Traditionally, packet capture inspections happen out of band and potentially at a future date. With TLS 1.3, packet inspection out of band becomes increasingly tricky. Since TLS 1.3 is a perfect forward secret by default, the symmetric key used during sessions is ephemeral. This means you will need every ephemeral key generated during a session to decrypt out of band. This creates challenges with the SOC and your threat hunters. F5 can help with its SSL Orchestration solution. By orchestrating decrypted traffic to your security inspection stack and re-encrypting it to your applications, you can utilize all the strong security features of TLS 1.3 and PQC while still providing complete visibility into your data-plane traffic. Additional Distinctions F5's full-proxy architecture enables comprehensive traffic inspection and control that competitors cannot match. F5 provides a unified platform integrating ZTAA, application delivery, and enterprise-grade security capabilities. The platform also offers fast TLS decryption at large scale without slowing down performance. It also supports old applications and new web services. F5 adds advanced bot detection, fraud prevention, and API security capabilities that pure-play ZTNA vendors lack. F5's extensive identity provider partnerships include deep Microsoft Azure AD integration with Conditional Access policies, native Okta SAML/OIDC federation, and comprehensive custom LDAP/Active Directory support. Protocol support spans SAML, OAuth, OIDC, RADIUS, LDAP, and Active Directory with flexible deployment across on-premises, cloud, hybrid, and managed service models. Identity Aware Proxy - Key Capabilities APM's Identity Aware Proxy is F5's Zero Trust Application Access solution. We throw around a lot of acronyms in the IT industry, so I just wanted to get that out of the way and make it clear. As I mentioned earlier in this post, F5 can currently meet or partially meet 57 of the 152 targets listed in the DoD Zero Trust strategy guide. APM's IAP solution helps meet many of those 57 targets. Let’s look at some of these features in the access guided configuration. You can find it in the APM or Access Policy Manager’s GUI. If you would like to see a full walk-through sample config, check out this page for a great write-up and lab. Authentication and Authorization Authentication and authorization are at the forefront of any Zero Trust solution. APM provides for robust authentication and authorization integration out of the box. APM has deep integration with Active Directory and supports many of the identity SaaS providers, such as Okta, Ping, SailPoint, and Azure Entra ID. In the image above, MFA is a capability built into the GUI, which makes it very easy to implement a two-factor solution within your ZTAA solution. MFA should be a component of every Zero Trust solution, and F5 makes it easy to integrate with your favorite identity provider. Conditional and Contextual Access Another key component of any ZTAA solution is conditional and contextual access. The new perimeter in a zero-trust world doesn't really exist. We should prioritize protecting the data and application, rather than focusing on our network perimeter security. This is not completely true, as we will keep using network firewalls. But the main idea of zero trust is about data and strong identity, not gateways into our networks. Based on that last sentence, we must be able to interrogate both the user and the device they are accessing from. This involves checking a device's posture for an active firewall or determining its location and the time of day of access. Users should be required to provide a strong identity to include MFA and ABAC controls. In the image below, we show the contextual configuration options for Identity Aware Proxy. This capability makes it easy to configure complex if-then logic flows. Another strong capability sometimes overlooked is APM's ability to query third-party systems for additional context. The HTTP Connector, as shown below, allows the administrator to configure a third-party risk score provider or additional telemetry for access decisions. This is all done via API calls, and so it makes interoperability seamless with other ecosystem vendors. Conclusion ZTAA is the change from zero trust architecture to application-focused security. It offers better performance, strong identity, lower costs, and more flexibility than traditional ZTNA approaches. F5 leads this transformation through its authentication and authorization technology platform, comprehensive application security capabilities, and proven enterprise deployment success across federal and civilian agencies. Organizations evaluating zero trust solutions should prioritize ZTAA for their application portfolios, cloud-native environments, and performance-critical deployments. F5's unified platform approach, technical differentiators, and market-leading capabilities make it the clear choice for enterprises seeking comprehensive zero-trust application access solutions that scale with business growth and digital transformation initiatives.NIST SP 800-53r4 iApp template
Problem this snippet solves: This iApp template helps you configure BIG-IP to support security controls consonant with NIST Special Publication 800-53r4. This iApp focuses on management of the BIG-IP itself rather than control of application traffic through the BIG-IP. For more details on this iApp and how it supports NIST Special Publication 800-53r4, enable the Inline Help within the template. The Help tab in the GUI contains additional information. The associated deployment guide is now available at http://www.f5.com/pdf/deployment-guides/nist-sp-800-53-r4-dg.pdf Fully supported version v1.0.0 - Supported release Released the fully supported version of the NIST iApp on 02-08-17. There were no additional changes to the iApp template over RC-6, however the iApp now supports BIG-IP versions 11.5.3 - 12.1.2. See https://support.f5.com/csp/article/K09154349 for instructions on downloading, importing and using the iApp. Release Candidate versions v1.0.1rc3 and rc4 RC3 was released on downloads.f5.com with a single fix (corrected an issue where the iApp would incorrectly detect Appliance Mode). As a part of this fix, the iApp would not load on BIG-IP systems that had a previous version of the NIST iApp. F5 released RC4 on DevCentral with a fix for this issue, and now the iApp loads properly on all devices. This version also contains a fix for multi-line banners and a fix for SNMP so the iApp catches any form of 127.0.0.0 and maps it. Released 1.0.1rc4 of the NIST iApp on 06-18-2018. v1.0.1rc1 Released 1.0.1rc1 of the NIST iApp on 08-18-2017. This version corrects an issue that would cause iApp Failure when configuring custom ports for self IP port lockdown v1.0.0rc6 Released RC-6 of the NIST iApp on 12-12-2016. In RC-6, all customer secrets/passwords in the iApp template are now securely stored. Previously, although secrets were stored in Secure Vault for use, some may have been stored in cleartext in the iApp reconfiguration data.* Added support for BIG-IP versions 12.1 and 12.1.1. Made error messages produced by the template easier to understand. If using RADIUS authentication, you are now limited a maximum of 10 servers. Previously there was no limit. The source-IP option on additional syslog servers is honored in this version. Previously this field was ignored. v1.0.0rc5 Released RC-5 of the NIST iApp on 12-16-2015. RC-5 adds a new question to the iApp template if you specified LDAP as your authentication method, asking if the directory user objects include group-membership attributes (like memberOf). Adds All as an option for remote-role partition access Other minor bug fixes. v1.0.0rc4 Released RC-4 of the NIST iApp on 12-02-2015. RC-4 adds support for BIG-IP v11.5.3. The main difference is the "Fraud Protection Manager" role was not available in 11.5.3, and only v11.6 and later.* Added the iRule Manager role that was missing in previous versions of the iApp. Clarified the answers and inline help for the MCPD audit log section. v1.0.0rc3 Released RC-3 of the NIST iApp on 11-12-2015. RC-3 contains mostly clarifications to the iApp presentation, including question/answer text and the inline help. Added warning messages where applicable. For the Management Access and SNMP Access IP addresses sections, removed the option to not allow any IP addresses, as this could cause issues, such as users inadvertently locking themselves out of the system. v1.0.0rc2 Released RC-2 of the NIST iApp on 10-30-2015. RC-2 corrects an issue where the option to revert to the pre-iApp configuration was not working properly.* Enhanced the management of self-IP access policies. Changes are now saved as the default for use with new self-IP objects as well as applied to existing self IP objects. Code : 88573
