FIPS 140-3 compliance tends to come up at an inconvenient time — usually during a sales process with a U.S. federal agency or a large enterprise customer with strict procurement requirements. By then, retrofitting it is expensive and stressful. This guide is for Israeli startups that want to get ahead of it.
What FIPS 140-3 Is
FIPS 140-3 (Federal Information Processing Standard 140-3) is a U.S. government standard for cryptographic modules. If a cryptographic module — software or hardware that implements encryption, hashing, key generation, or random number generation — is used to protect sensitive federal information, it must be validated to FIPS 140-3.
“Validated” means the module has been tested and certified by an accredited Cryptographic Module Testing Laboratory (CMTL) and appears on NIST’s Cryptographic Module Validation Program (CMVP) list.
For Israeli startups, FIPS 140-3 matters when:
- You’re selling to U.S. federal government agencies (FedRAMP authorization requires it)
- Your enterprise customers have internal security policies requiring FIPS-validated cryptography
- You’re pursuing compliance frameworks like DISA STIGs, DoD IL2/IL4, or similar
It does not apply to purely private-sector commercial use unless your customer’s contracts require it.
What FIPS 140-3 Requires in Practice
The standard applies to the cryptographic module itself, not to every line of your application code. What this means practically:
- The encryption libraries or hardware security modules (HSMs) you use must be FIPS-validated
- You must use only the approved algorithms listed in the standard (AES, SHA-2/3, RSA, ECDSA, etc.)
- You must not configure the module to use non-approved algorithms, even if the library supports them
Common traps:
- Using an older TLS cipher suite that includes RC4, MD5, or export-grade ciphers
- Enabling non-FIPS algorithms as a fallback “for compatibility”
- Using a cryptographic library that hasn’t been FIPS-validated, even if it implements approved algorithms correctly
AWS and FIPS 140-3
AWS has done significant work to offer FIPS-validated services and endpoints. Here’s what matters:
AWS GovCloud vs. Standard Regions
AWS GovCloud (US-East and US-West) is specifically designed for U.S. government workloads and meets FedRAMP High authorization. If you’re selling to U.S. federal agencies and need to meet FedRAMP, GovCloud is the starting point.
For Israeli startups that need FIPS compliance for enterprise customers but aren’t pursuing FedRAMP specifically, standard AWS regions can often meet requirements if you use FIPS endpoints and validated services.
FIPS Endpoints
AWS offers FIPS 140-2/140-3 validated endpoints for most core services. When you connect to s3.us-east-1.amazonaws.com, you’re using a standard TLS endpoint. When you connect to s3-fips.us-east-1.amazonaws.com, you’re using a FIPS-validated endpoint that enforces approved TLS cipher suites.
Services with FIPS endpoints include: S3, EC2 APIs, IAM, KMS, STS, CloudTrail, and many others. Check the AWS FIPS endpoints documentation for the current list — it expands regularly.
To enforce FIPS endpoints across your AWS SDK calls, set the use_fips_endpoint flag in your AWS SDK configuration:
# AWS SDK config (~/.aws/config)
[default]
use_fips_endpoint = true
AWS KMS
AWS Key Management Service (KMS) uses FIPS 140-2 validated HSMs by default in standard regions. For key material that needs FIPS 140-3 validation, use AWS CloudHSM with a FIPS 140-3 Level 3 validated module.
For most enterprise compliance requirements, KMS with FIPS endpoints is sufficient. CloudHSM is needed only when you require exclusive control over your HSM or need to generate key material entirely outside of shared infrastructure.
TLS Configuration
Your application’s TLS configuration needs to enforce FIPS-approved cipher suites. Concretely, this means:
- TLS 1.2 minimum (TLS 1.3 is preferred)
- Cipher suites: AES-GCM variants, ECDHE for key exchange
- No RC4, DES, 3DES, MD5, or export-grade ciphers
Approved TLS 1.2 cipher suites (examples):
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Not approved:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Any export cipher suite
If you’re running your own TLS termination (nginx, Caddy, your application server), audit your cipher configuration. Many default configurations include non-approved ciphers for backwards compatibility.
What Auditors Actually Check
FIPS compliance audits for enterprise customers are typically less rigorous than a formal FedRAMP assessment, but they tend to focus on the same things:
- Are your cryptographic libraries FIPS-validated? If you’re using OpenSSL in FIPS mode, can you demonstrate that the module is certified?
- Are your endpoints FIPS? Can you show that API calls to AWS use FIPS endpoints?
- Is your TLS configuration restricted to approved ciphers? Show your TLS configuration or provide a scan output from a tool like
testssl.sh. - How are your encryption keys managed? Who can access KMS, how is key rotation handled, and are key operations logged in CloudTrail?
- Is key material ever stored in plaintext? Secrets management practices (AWS Secrets Manager, Parameter Store) vs. hardcoded credentials in environment variables.
Having documentation for each of these will satisfy the majority of enterprise security questionnaires that reference FIPS 140-3.
A Practical Checklist
| Area | Action |
|---|---|
| AWS SDK | Enable use_fips_endpoint = true in all environments |
| TLS | Audit cipher configuration; disable non-approved suites |
| Key management | Use AWS KMS for all encryption keys; enable CloudTrail logging for KMS |
| Cryptographic libraries | Verify any language-level crypto libraries are FIPS-validated (e.g., BoringCrypto for Go, OpenSSL in FIPS mode for Python/C) |
| Secrets | Store secrets in AWS Secrets Manager or Parameter Store; no plaintext in env vars or config files |
| Documentation | Maintain a crypto inventory — what’s encrypted, with what algorithm, using which key |
The Bottom Line
FIPS 140-3 compliance is not as technically complex as its reputation suggests. The bulk of the work for an AWS-native Israeli startup is: switch to FIPS endpoints, audit your TLS configuration, use KMS for key management, and verify that your cryptographic libraries are validated. Most of these are configuration changes, not architectural ones.
The hard part is usually documentation and process — demonstrating to an auditor that you’ve done these things and that you maintain them. Build that documentation as you implement the controls.
If you want to discuss how Xpernix can help you track compliance posture across your AWS environment, contact us.