CipherGap Limitations
CipherGap is designed to provide practical visibility into observable post-quantum TLS readiness. Like any external scanner, it has limits.
This page explains what CipherGap can and cannot prove.
External Visibility Only
CipherGap tests what is visible from the public internet.
If a service is internal, private, authenticated, allow-listed, behind a VPN, or only reachable from specific networks, CipherGap may not be able to assess it.
A clean result for a public hostname does not prove that internal services, origin servers, APIs, admin portals, or private endpoints have the same posture.
Point-in-Time Results
Each scan reflects what CipherGap observed at the time of testing.
TLS behavior can change based on:
- CDN configuration.
- Load balancer configuration.
- Regional routing.
- DNS changes.
- Certificate rotation.
- Cloud provider changes.
- Client compatibility settings.
- Maintenance windows.
- Security policy changes.
Monitoring helps detect drift, but no scan can guarantee that the result will remain true indefinitely.
CDN and Edge Provider Behavior
Many public websites are served through CDNs, reverse proxies, web application firewalls, and cloud edge platforms.
When CipherGap scans a hostname, the observed result may reflect the edge provider rather than the true origin server.
For example, a CDN may support hybrid post-quantum TLS for visitor-to-edge connections while the origin connection remains classical. The reverse may also be true in some architectures.
CipherGap reports what is externally observable. It may not be able to determine the complete cryptographic posture between every internal hop.
Key Exchange Is Not the Same as Full Post-Quantum Security
CipherGap’s post-quantum TLS readiness signal focuses primarily on hybrid post-quantum key exchange.
Key exchange protects how session keys are established. It is only one part of HTTPS security.
A service may support hybrid post-quantum key exchange while still using classical certificate signatures such as RSA or ECDSA. That is common during the current public web transition.
CipherGap should not be interpreted as proof that a service is fully post-quantum across authentication, certificates, code signing, document signing, internal PKI, application encryption, stored data, or all dependent systems.
Client Support Still Matters
Post-quantum TLS negotiation requires support from both sides of the connection.
A server may support hybrid post-quantum key exchange, but clients that do not offer compatible algorithms may still negotiate classical TLS.
CipherGap reports whether the scanned endpoint negotiated post-quantum key exchange with CipherGap’s scanner. It does not prove that every real user, browser, application, API client, or legacy system will negotiate the same result.
TLS 1.3 Dependency
Post-quantum key exchange for modern HTTPS deployments is tied to TLS 1.3-based negotiation.
If a service does not support TLS 1.3, it should generally be considered not ready for current public web post-quantum key exchange patterns.
However, TLS 1.3 support alone does not guarantee post-quantum support.
Middleboxes and Compatibility Issues
Some networks and appliances interfere with modern TLS behavior.
Potential sources of interference include:
- TLS inspection devices.
- Legacy load balancers.
- Web application firewalls.
- Proxies.
- DLP tools.
- SSL decryption platforms.
- Legacy clients.
- Custom TLS stacks.
CipherGap can report what it observes externally, but it may not always be able to identify which device or policy caused a negotiation failure.
False Positives and False Negatives
CipherGap is built to reduce ambiguity, but external TLS scanning can still produce incomplete or misleading results.
A result may be affected by:
- Temporary network errors.
- DNS inconsistency.
- Geo-based routing.
- IPv4 and IPv6 differences.
- CDN point-of-presence differences.
- Rate limiting.
- Firewall policy.
- SNI-specific behavior.
- Certificate chain variation.
- Server-side A/B testing.
- Intermittent platform changes.
When a result is unexpected, users should confirm with additional testing and review the platform configuration directly.
No Guarantee of Compliance
CipherGap does not certify compliance with any law, regulation, framework, or contractual requirement.
CipherGap can provide useful evidence for security reviews, vendor discussions, and migration planning, but final compliance interpretation belongs to the organization, auditor, assessor, or governing authority.
No Penetration Testing
CipherGap does not perform penetration testing.
CipherGap does not:
- Exploit vulnerabilities.
- Attempt authentication bypass.
- Guess credentials.
- Test application logic.
- Perform denial-of-service testing.
- Access private data.
- Scan internal networks without explicit capability and authorization.
- Validate every cryptographic dependency in an application stack.
CipherGap is a cryptographic exposure and TLS readiness tool, not a full security assessment platform.
No Complete Cryptographic Inventory
CipherGap currently evaluates submitted internet-facing hostnames.
It may not identify every place where classical cryptography exists, including:
- Internal services.
- Databases.
- Message queues.
- VPNs.
- SSH services.
- Email services.
- Embedded devices.
- Mobile applications.
- Thick clients.
- Code signing.
- Document signing.
- Backup encryption.
- Application-layer encryption.
- Third-party SaaS dependencies.
Organizations planning a post-quantum migration should pair external scanning with a broader cryptographic inventory program.
Recommended Interpretation
Use CipherGap results as directional, evidence-backed visibility into externally observable TLS readiness.
A strong result means the scanned endpoint demonstrated better readiness during the scan.
A weak result means the endpoint needs review, remediation, vendor engagement, or compensating context.
An inconclusive result means CipherGap could not collect enough reliable evidence to make a strong determination.
CipherGap helps answer: “What can we observe from the outside, what changed, and what should we investigate next?”