Cryptography for AWS-LC Environments
Build, deploy, and maintain AWS-LC-based applications with enterprise-supported cryptographic software designed for FIPS 140-3 certification, customer-owned validation, OpenSSL 1.1.1 API compatibility, long-term lifecycle support, and post-quantum readiness.
FIPS 140-3 Cryptography for
AWS-LC-Based Architectures
AWS Libcrypto (AWS-LC) is a general-purpose cryptographic library maintained by the AWS Cryptography team and derived from BoringSSL and OpenSSL. It is designed for performance, security, and portability across modern applications and infrastructure.
AWS-LC aims to maintain API compatibility with OpenSSL 1.1.1, making it especially relevant for C and C++ applications that depend on established OpenSSL 1.1.x interfaces but want to adopt the AWS-LC ecosystem. AWS-LC does not provide ABI compatibility with OpenSSL, however, so applications must be rebuilt and tested against the library rather than simply swapping shared binaries.
AWS also maintains FIPS 140-3 validated AWS-LC cryptographic modules. For AWS-LC FIPS 3.1.0, NIST maintains separate active validations for dynamic and static module configurations.
But using AWS-LC—or even incorporating an upstream validated AWS-LC module—does not automatically give your organization a dedicated FIPS 140-3 certificate under its own name or eliminate the engineering work required to preserve the validated configuration over time.
Product teams must account for API compatibility, build and linking model, approved-service verification, operating environment coverage, AWS-LC release and FIPS branch lifecycles, certificate ownership, and long-term software maintenance.
SafeLogic is bringing AWS-LC into the CryptoComply ecosystem with enterprise software support, accelerated customer-owned FIPS certification, and ongoing lifecycle services—helping organizations adopt AWS-LC while reducing the certification and maintenance burden associated with regulated deployments.
The Technical and Compliance
Burden of AWS-LC
AWS-LC provides a modern cryptographic foundation with familiar OpenSSL-style APIs but integrating it into a regulated commercial product introduces architectural and lifecycle decisions that do not exist in a simple open-source library upgrade.
AWS-LC’s compatibility model, static and dynamic builds, FIPS service indicators, validation snapshots, LTS branches, operating environments, and upstream certificate ownership all affect how engineering teams maintain a compliant product.
Six engineering realities deserve particular attention:
1. OpenSSL 1.1.1 API Compatibility Without ABI Compatibility
AWS-LC aims to be API compatible with the OpenSSL 1.1.1 API surface, but it does not promise identical behavior for every OpenSSL feature and is not ABI compatible with OpenSSL. AWS-LC’s own porting guidance states that applications cannot directly swap an existing OpenSSL binary for AWS-LC without recompiling.
- Recompilation Required: Applications migrating from OpenSSL must be rebuilt against AWS-LC rather than relying on binary-level substitution.
- Behavioral Differences: Missing APIs, changed defaults, removed functionality, or lower-level behavioral differences can require application-specific changes.
- Compatibility Testing: Applications should be compiled and exercised against their existing test suites to identify assumptions that do not carry cleanly from OpenSSL.
This makes AWS-LC particularly relevant for applications targeting an OpenSSL 1.1.1-style API model—but distinctly different from an OpenSSL 3.x Provider-based migration.
2. Static vs. Dynamic Linking Changes the Validation Story
For AWS-LC FIPS 3.1.0, static and dynamic implementations are covered by separate NIST CMVP certificates.
The validated cryptographic boundary in both cases is based on the bcm.o module, but the way that module is incorporated into the application differs. Under the dynamic validation, the module is dynamically linked into the userspace application. Under the corresponding static validation, it is statically linked during compilation.
- Separate Validations: AWS-LC FIPS 3.1.0 dynamic and static modules have distinct CMVP certificates rather than one certificate covering both linking models.
- Build Pipeline Impact: Engineering teams must preserve the linking model associated with the intended validation throughout build and release processes.
- Runtime Verification: The applicable Security Policy provides mechanisms for verifying whether an application is dynamically or statically linked to the module.
For the AWS-LC 3.1.0 dynamic validation, for example, an undefined awslc_version_string symbol in the application confirms dynamic linkage under the documented verification procedure.
3. Approved vs. Non-Approved Cryptographic Service Verification
AWS-LC’s validated module can execute both approved and non-approved services.
The module automatically enters the applicable mode depending on the service requested, making runtime service verification an important part of applications that need to demonstrate approved cryptographic operation.
AWS-LC provides a FIPS service indicator that applications can use to determine whether a cryptographic service was approved.
- Service-Level Verification: FIPS posture depends on which cryptographic operation is invoked, not simply whether the AWS-LC FIPS module is present.
- Approved-Service Controls: Applications should ensure that regulated cryptographic operations use approved algorithms, parameters, and services.
- Runtime Assurance: Engineering and test pipelines can incorporate service-indicator checks to verify that critical operations execute through the expected approved path.
This provides useful visibility—but also places responsibility on product teams to understand and test which AWS-LC operations their applications actually invoke.
4. AWS-LC Versioning, FIPS Snapshots, and LTS Lifecycle Complexity
AWS-LC’s software lifecycle differs from conventional Semantic Versioning.
AWS-LC explicitly states that its major version numbers do not follow SemVer and do not necessarily indicate API or ABI breaking changes. Public API changes can instead be tracked through AWSLC_API_VERSION. AWS-LC software versioning is also now independent from its FIPS submission version.
The project currently maintains several release models:
- Rolling Mainline: Receives new features, performance improvements, and security fixes and is targeted for FIPS submission approximately every six months.
- LTS Branches: Cut approximately every two years and supported for five years. Each LTS branch is submitted for FIPS validation.
- Non-LTS FIPS Snapshots: Preserve fixed source snapshots submitted for validation but are not intended to operate as long-term consumer release branches. Once superseded, they can be frozen without further updates.
This creates a strategic decision for product teams: choosing an AWS-LC version is also choosing an upgrade, support, and FIPS-maintenance strategy.
5. Operating Environment Coverage and Build Reproducibility
AWS-LC itself supports and tests a broad range of platforms, including Linux, Windows, macOS, Android, x86-64, and ARM architectures. But general AWS-LC platform support should not be confused with the operating environments covered by a specific FIPS validation.
For example, the AWS-LC FIPS 3.1.0 dynamic Security Policy identifies specific Amazon Linux 2023 environments on Graviton4 and Intel Xeon hardware and lists no vendor-affirmed operating environments.
- Platform Support ≠ Validation Coverage: An application may successfully run AWS-LC on a platform that is not represented in the applicable FIPS validation.
- Build Reproducibility: The validated module depends on the defined source, build procedures, integrity controls, and configuration described in the Security Policy.
- Deployment Drift: Changes to operating systems, processors, cloud instance types, build options, or packaging models can require compliance review.
Engineering teams should therefore evaluate the exact environments their customers deploy rather than assuming broad open-source portability automatically translates into FIPS coverage.
6. Upstream Validation vs. Customer-Owned Certification and Support
AWS maintains its own AWS-LC FIPS validations. Those validations establish the status of the specified AWS cryptographic module—but they do not give every downstream software vendor a CMVP certificate under its own name.
AWS-LC’s own FIPS documentation also directs questions about FIPS compliance and FIPS-compliant deployment to accredited CMVP laboratories or compliance specialists rather than providing compliance guidance directly.
For commercial software vendors, that creates two separate needs:
- Certificate Ownership: A dedicated FIPS certificate provides customers, auditors, and procurement teams with a validation record associated with your organization.
- Enterprise Support: Product teams need support for integration, deployment, cryptographic configuration, vulnerability response, and complex customer environments.
- Lifecycle Control: A managed certification strategy helps align cryptographic maintenance with your product roadmap rather than depending entirely on upstream release and validation decisions.
RapidCert™ provides an accelerated path toward customer-owned FIPS certification, while MaintainCert™ supports ongoing software and certificate maintenance as products and environments evolve.
ENGINEERING TAKEAWAY:
AWS-LC offers a modern, high-performance cryptographic foundation with OpenSSL 1.1.1-oriented APIs, but regulated commercial deployment requires control over much more than the library itself. Linking model, approved-service verification, operating environment coverage, version and FIPS branch lifecycles, certification ownership, and long-term support all become part of the product architecture.
Defining the FIPS 140-3 Cryptographic
Boundary in AWS-LC Applications
The validated AWS-LC cryptographic module is narrower than the complete AWS-LC library or application. For AWS-LC FIPS 3.1.0, the Security Policy defines the cryptographic boundary around the bcm.o module. In the dynamic configuration, that module is dynamically linked into the userspace application. Other AWS-LC functionality, application logic, the operating system, and supporting infrastructure remain outside the cryptographic boundary.
AWS-LC BASED APPLICATION
Enterprise Applications, Cloud Services, Appliances, Middleware, Client Software
AWS-LC LIBRARY / OPENSSL 1.1.1-COMPATIBLE APIs
OpenSSL 1.1.1 API Compatible Functions
CALLS TO APPROVED CRYPTOGRAPHIC SERVICES
FIPS 140-3 VALIDATED CRYPTOGRAPHIC BOUNDARY
CryptoComply based on AWS-LC
Example of approved Cryptographic Services
AES / GCM Symmetric Encryption
SHA-1 / SHA-2 / SHA-3 Hash Functions
HMAC Message Authentication and Integrity
RSA Asymmetric Cryptography
ECDSA / EdDSA Digital Signatures
KAS-ECC-SSC EC Key Agreement
ML-KEM Post-Quantum Key Establishment
CTR-DRBG Deterministic Random Bit Generation
Outside the Validated Boundary
Inside the Validated Boundary
Approved cryptographic operations must execute through the validated module using the configuration, linking model, integrity controls, approved services, and operating environments associated with the applicable Security Policy.
For products based on the dynamic module, engineering teams must also preserve and verify dynamic linking throughout the build and deployment process.
Architecture Checklist: Evaluating AWS-LC-Compatible FIPS Software
Engineering, security, and compliance teams evaluating AWS-LC-based cryptographic software should verify:
OpenSSL 1.1.1 API Fit
Does AWS-LC provide the APIs your application currently depends on, and have known behavioral differences been tested?
Static vs. Dynamic Linking
Which linking model does your product require, and does it match the applicable FIPS validation?
Cryptographic Boundary Integrity
Are the validated module, integrity controls, and required startup procedures preserved through CI/CD and packaging?
Corporate Certificate Ownership
Can your organization obtain a dedicated CMVP certificate rather than relying exclusively on AWS’s upstream certificate?
PQC & Crypto-Agility Roadmap
Does the architecture provide a path to standardized post-quantum algorithms and hybrid migration as cryptographic requirements evolve?
Rebuild Requirements
Can your build system cleanly compile and link the application against AWS-LC rather than relying on OpenSSL ABI compatibility?
Approved-Service Verification
Can your application and test environment verify that regulated operations invoke approved cryptographic services?
Operating Environment Coverage
Are the operating systems, processor architectures, cloud targets, and deployment environments required by your customers covered by the intended validation strategy?
Lifecycle Strategy
How will the product handle AWS-LC mainline changes, LTS branches, FIPS snapshots, CVEs, and end-of-support transitions?
SafeLogic Product Path for FIPS 140 AWS-LC Architectures
SafeLogic is extending the CryptoComply ecosystem to support organizations building products around AWS-LC:
CryptoComply AWS-LC
Preserve AWS-LC and OpenSSL 1.1.1-oriented application interfaces while adding enterprise software support and an accelerated path to customer-owned FIPS 140-3 certification.
RapidCert™
Accelerate the path to a customer-owned FIPS 140-3 certificate using SafeLogic’s validated cryptographic foundation rather than beginning a traditional module validation effort from scratch.
MaintainCert™
Maintain CryptoComply software and FIPS certificate coverage as vulnerabilities emerge, Java and Bouncy Castle dependencies evolve, operating environments change, and product releases continue.
Looking for OpenSSL 3.x Compatibility?
AWS-LC targets an OpenSSL 1.1.1-style API surface rather than the OpenSSL 3.x Provider architecture.
For applications standardized on OpenSSL 3.x, CryptoComply Core provides SafeLogic’s OpenSSL 3.x-compatible product path.
Post-Quantum Cryptography & Governance in AWS-LC Stacks
AWS-LC is already moving into the post-quantum era.
The AWS-LC FIPS 3.1.0 validation includes ML-KEM within its approved cryptographic capabilities, providing a validated foundation for post-quantum key establishment alongside established classical cryptography.
That creates an opportunity for organizations adopting AWS-LC today to design cryptographic agility rather than treating PQC as a separate future migration.
SafeLogic can help product teams evaluate where ML-KEM and future post-quantum capabilities fit into their application architecture while maintaining the certification, governance, and lifecycle controls required in regulated environments.
Enterprise Quantum Strategy with SafePQ
For environments where FIPS validation is not the primary requirement, SafePQ provides a broader path for standardized post-quantum and hybrid cryptography across heterogeneous applications and infrastructure.
Explore Open-Source
Cryptography Compatibility
Building products across multiple cryptographic ecosystems? SafeLogic helps engineering teams adopt validated cryptography while preserving the compatibility their applications require.
OpenSSL
CryptoComply Core provides OpenSSL-compatible cryptographic software for systems, applications, embedded products, and infrastructure.
BoringCrypto
CryptoComply BoringCrypto supports products built around BoringSSL and Google’s BoringCrypto implementation.
Bouncy Castle
CryptoComply Java provides FIPS 140-3 validated, BC-FJA-compatible cryptographic software for Java applications and JVM environments.
AWS-LC and FIPS 140 FAQs
Is AWS-LC FIPS 140-3 validated?
Yes, specific AWS-LC cryptographic modules and configurations have received FIPS 140-3 validation.
For AWS-LC FIPS 3.1.0, NIST maintains separate active validations for dynamic and static module configurations. FIPS status applies to the defined module operating according to the applicable Security Policy—not automatically to every AWS-LC build or every application that uses AWS-LC.
Is AWS-LC a drop-in replacement for OpenSSL 1.1.1?
Not at the binary level.
AWS-LC aims to provide API compatibility with OpenSSL 1.1.1, but it is not ABI compatible with OpenSSL. Applications generally need to be recompiled against AWS-LC, and AWS recommends testing missing APIs, behavioral differences, and application-specific assumptions during migration.
Does the same AWS-LC FIPS certificate cover both static and dynamic linking?
No. AWS-LC FIPS 3.1.0 uses separate FIPS 140-3 validations for its dynamic and static module configurations.
The cryptographic module is based on bcm.o in both cases, but the dynamic module is dynamically linked into the userspace application while the static module is incorporated through static linking.
Engineering teams should make sure their build, and deployment model aligns with the intended validation.
How can an AWS-LC application determine whether a cryptographic operation is FIPS approved?
AWS-LC provides a service-indicator mechanism that applications can use to determine whether an invoked cryptographic service was approved.
The documented interface checks the state before and after a service call and reports whether the operation was executed as an approved service.
This allows engineering teams to incorporate approved-service verification into application testing and compliance controls.
Why use SafeLogic instead of relying on AWS's upstream FIPS validation?
AWS’s validation establishes the status of the specified AWS-LC cryptographic module. It does not provide every downstream product vendor with a CMVP certificate under its own organization.
SafeLogic combines AWS-LC-based cryptographic software with enterprise support, RapidCert™ for customer-owned certification, and MaintainCert™ for ongoing software and certificate maintenance.
This gives product teams greater control over certification, support, security updates, operating environments, and long-term product planning.
How does AWS-LC versioning affect FIPS deployments?
AWS-LC software versions and FIPS submission versions are now separate.
AWS-LC does not use Semantic Versioning in the conventional sense, and major-version changes do not necessarily mean API-breaking changes. The project also distinguishes rolling mainline, long-term support branches, and non-LTS FIPS validation snapshots.
Teams building regulated products should therefore track the AWS-LC software version, FIPS version, branch type, and support window rather than relying on the version number alone.
Does AWS-LC support post-quantum cryptography?
Yes. AWS-LC FIPS 3.1.0 includes ML-KEM as an approved cryptographic capability, providing standardized post-quantum key establishment within the validated module.
Additional post-quantum capabilities should be evaluated against the specific AWS-LC release and FIPS validation being deployed rather than assuming that every algorithm present in upstream AWS-LC is included within a particular validated module.
Which operating environments are covered by AWS-LC FIPS validation?
Coverage depends on the specific AWS-LC module and certificate.
For example, the AWS-LC FIPS 3.1.0 dynamic validation identifies tested Amazon Linux 2023 environments using Graviton4 and Intel Xeon processors and does not list vendor-affirmed operating environments.
Organizations should verify the exact operating environments covered by their intended SafeLogic certification and deployment strategy before release.
Modernize AWS-LC-Based Cryptography with SafeLogic
Preserve the AWS-LC architecture and OpenSSL 1.1.1-style interfaces your applications rely on while establishing a clearer path to customer-owned FIPS 140-3 certification, enterprise support, lifecycle maintenance, and post-quantum readiness.
