You need to know you are communicating with the right system, not an impostor. SC.L2-3.13.15 requires mechanisms to verify the authenticity of communications partners. This is primarily handled through TLS certificates and digital signatures. The assessor will check that your systems verify certificates and that authenticity is protected. See SC.L2-3.13.8 for encryption in transit and SC.L2-3.13.10 for key and certificate management.
What the assessor is actually evaluating
The assessor will look for:
TLS implementation: Web servers and APIs should use TLS with valid certificates. Certificate hostname must match the domain being accessed.
Certificate validation: Client systems should validate server certificates. They should not accept expired, self-signed, or mismatched certificates.
Certificate management: Certificates should be from trusted CAs. Internal CAs should be properly configured and their root certificates trusted.
Mutual authentication: Where sensitive systems communicate, mutual TLS (mTLS) should be used so both systems authenticate each other.
What a realistic SSP definition looks like
Policy: “The organization uses TLS with valid X.509 certificates to authenticate network communications. All HTTPS connections use certificates issued by trusted CAs. Internal communications can use self-signed certificates only if endpoint validation is configured. All client applications validate server certificates and reject invalid certificates.”
Supporting details:
- Public-facing systems: Web servers use certificates from DigiCert or similar trusted CA. Certificates are valid and match the domain.
- Internal systems: Internal communications use TLS with self-signed certificates from the internal CA. Client systems are configured to trust the internal CA root certificate.
- Certificate validation: Applications are configured to validate certificates and reject connections to servers with invalid certificates.
- Mutual TLS: APIs and sensitive integrations use mTLS where both client and server authenticate each other.
- Certificate renewal: Certificates are renewed before expiration. A 30-day reminder process ensures no expired certificates are in use.
How to present your evidence
- Authentication policy document: Describes TLS requirements, certificate management, and validation procedures.
- Certificate information: For each public-facing service, provide the certificate details (issuer, subject, expiration date, key size). Show certificates are valid and from trusted CAs.
- Certificate validation configuration: For applications and systems, show that certificate validation is enabled. Configuration files or application settings should show validation is not disabled.
- Internal CA documentation: If internal CAs are used, document the root certificate, how it is distributed, and how client systems are configured to trust it.
- Certificate renewal records: Documentation of certificate renewals over the past year showing no expired certificates.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Assessor: “How do you protect the authenticity of communications? What mechanisms do you use?”
You: “We use TLS with valid X.509 certificates. Public-facing servers use trusted CA certificates. Internal systems use self-signed certificates with proper validation configured.” [Pull up authentication policy and certificate details]
Assessor: “Show me a TLS certificate from one of your web servers.”
You: [Open the certificate in a browser and show issuer (trusted CA), subject (domain name), and expiration date. Show it is valid.]
Assessor: “How does a client system validate this certificate?”
You: “The client checks that the certificate is from a trusted CA, that the domain name matches, and that the certificate has not expired. Invalid certificates are rejected.” [Show application or system settings enforcing certificate validation]
Assessor: “What if a system tries to disable certificate validation?”
You: “Some systems allow disabling validation for debugging, but it is not permitted for production systems. We have a policy against it.” [Show policy and configuration preventing validation bypass in production]
Common failures
Systems accept any certificate: Applications or systems are configured with “InsecureSkipVerify” or similar settings. They do not validate certificates at all.
Expired certificates: TLS certificates have expired and are no longer valid. Systems using them have authentication failures.
Self-signed certificates without proper validation: Internal systems use self-signed certificates, but client systems are not configured to trust the internal CA. Certificate validation fails or is disabled.
No mutual authentication: When sensitive systems communicate, only the server is authenticated. The client is not authenticated.
Valid, trusted certificates: Public-facing systems have certificates from trusted CAs. Certificates are valid and match the domain.
Enforced certificate validation: Systems validate certificates and reject invalid ones. Configuration prevents validation bypass.
Proper internal CA setup: Internal certificates are signed by a trusted internal CA. Client systems trust the CA and validate internal certificates correctly.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If your MSP manages web servers or systems, ensure the service agreement specifies that valid, trusted TLS certificates will be used. Request the certificates and verify they are valid and from trusted CAs. Ensure client systems are configured to validate certificates properly.
This guide is for reference only and does not replace official CMMC documentation or professional compliance advice.