Which Logs Prove Session Authenticity Maturity? (SC.L2-3.13.15)

The strongest session authenticity maturity evidence logs combine authentication events, TLS or mutual-TLS handshake records, certificate-validation records, VPN or zero-trust access logs, and SIEM correlation showing that unauthenticated or invalid peers were blocked. For SC.L2-3.13.15, an organization is mature when it can demonstrate not only that approved protocols establish trust between both ends of a communications session, but also that it consistently monitors, investigates, and improves exceptions. A proposal response should therefore present evidence as a scored operating capability rather than a binary statement that TLS is enabled.

Why is maturity scoring better than a binary checklist?

NIST SP 800-171 Rev. 2 practice SC.L2-3.13.15 requires an organization to protect the authenticity of communications sessions. Under CMMC 2.0 Level 2, the assessor is not simply looking for a protocol name in a network diagram; the organization must show that the implemented mechanism establishes a reliable trust relationship between session endpoints.

A binary checklist can confirm that a web application uses HTTPS, a remote-access gateway uses MFA, or devices have certificates. It cannot reliably distinguish between a configuration that is present but inconsistently enforced and a control that is governed, monitored, and demonstrably effective. That distinction matters in an RFP because evaluators need confidence that the offeror can protect Federal Contract Information and Controlled Unclassified Information under operational pressure, not merely during an evidence collection exercise.

Maturity scoring gives proposal teams a defensible way to describe the current state, identify inherited-service dependencies, and commit to a realistic improvement path. It also avoids overclaiming. An organization with TLS 1.2 enabled but no certificate-expiration monitoring should not claim optimized session authenticity; it has a basic technical safeguard with a foreseeable failure mode.

Which session authenticity maturity evidence logs support each maturity score?

Level 1: Initial

At the Initial level, session authenticity depends on administrator knowledge and isolated default settings. HTTPS, VPN encryption, or MFA may exist, but the organization cannot consistently show which systems require authenticated sessions or whether unauthorized peers are rejected. Evidence is gathered manually and usually only after an incident, questionnaire, or audit request.

• Administrators provide screenshots showing HTTPS enabled in a web console or VPN configuration.
• Windows Event Viewer, firewall logs, or application logs may contain authentication events, but retention and review are inconsistent.
• Certificates may be self-signed, manually distributed, or allowed to expire without a tracked owner.
• Remote access may authenticate users, while service-to-service connections rely on unauthenticated internal network trust.

A proposal writer should characterize this level carefully: technical safeguards may be present, but repeatable proof is limited.

Level 2: Repeatable

At the Repeatable level, the organization has selected common mechanisms for major session types and can retrieve evidence when asked. Typical mechanisms include TLS for web services, IPsec or SSL VPN for remote access, Kerberos for domain services, and certificate-based authentication for managed devices. Teams follow a recurring process, even if it is not yet fully standardized across the enterprise.

• Microsoft Entra ID sign-in logs show successful and failed MFA-backed access sessions.
• Cisco AnyConnect or Palo Alto GlobalProtect logs show user identity, source IP address, gateway, connection time, and disconnect reason.
• F5 BIG-IP, NGINX, Apache, or AWS Application Load Balancer logs demonstrate approved TLS protocol and cipher negotiation.
• A certificate inventory identifies owner, issuing CA, common name or subject alternative name, and expiration date for significant systems.
• Security staff retain logs in Microsoft Sentinel, Splunk Enterprise, or Elastic for a defined period, such as 90 days searchable and one year archived.

Level 3: Defined

At the Defined level, the organization has documented and consistently implemented a session-authenticity standard. The standard identifies approved protocols, minimum versions, approved certificate authorities, authentication requirements by connection type, logging sources, retention expectations, and exception approval requirements. This is generally the practical target for a well-prepared CMMC Level 2 environment.

• A system security plan maps SC.L2-3.13.15 to specific safeguards, such as TLS 1.2 or TLS 1.3, mutual TLS for service APIs, and certificate-based device authentication.
• Configuration baselines disable SSL, TLS 1.0, TLS 1.1, anonymous cipher suites, and untrusted certificate chains.
• Mutual authentication is enforced for device-to-device, application-to-application, or administrative API sessions where the architecture requires both endpoints to validate identity.
• Certificate-validation failures, invalid client certificates, failed VPN authentication, and anomalous session establishment events are forwarded to the central SIEM.
• Change records document protocol changes, certificate rotations, and approved compensating controls for legacy interfaces.

Level 4: Managed

At the Managed level, control performance is measured and reviewed. The organization can show that session-authenticity failures are detected, triaged, and resolved within defined service levels. Evidence is correlated across identity, endpoint, network, and application layers, allowing reviewers to trace a session from an authenticated principal through an encrypted connection to the protected service.

• Microsoft Sentinel analytics or Splunk correlation searches alert on repeated failed client-certificate validation, deprecated TLS negotiation attempts, and successful VPN sessions from high-risk locations.
• Security operations personnel review dashboards for certificate expiration, handshake failures, failed mutual-TLS requests, and exceptions to approved cryptographic baselines.
• Metrics track items such as percentage of in-scope services using TLS 1.2 or higher, percentage of API connections using mutual TLS, and mean time to remediate certificate issues.
• Quarterly control reviews compare the approved asset inventory against observed TLS endpoints and identify unmanaged services.
• Incident tickets show investigation of suspicious session activity, including root cause and corrective action.

Level 5: Optimized

At the Optimized level, session authenticity is continuously improved through automation, risk intelligence, and architecture feedback. The organization reduces human dependence in certificate issuance, renewal, policy enforcement, and evidence collection. It tests whether controls work in realistic failure conditions rather than assuming that a successful configuration deployment remains effective.

• HashiCorp Vault PKI, Venafi, AWS Certificate Manager, or Microsoft Active Directory Certificate Services automates certificate lifecycle management with monitored renewal workflows.
• Policy-as-code checks in GitHub Actions, Azure DevOps, or Terraform Cloud block deployments that expose services without approved TLS settings or required client-certificate validation.
• Continuous external and internal scans identify expired certificates, weak ciphers, incomplete chains, and services accepting unauthenticated connections.
• Tabletop exercises and technical tests validate that expired, revoked, mismatched, or untrusted client certificates cannot establish protected sessions.
• Control owners use trend data to prioritize architectural modernization of legacy protocols and exception-heavy systems.

How can an organization score its session-authenticity maturity?

Score each row from 1 through 5 based on evidence that can be produced for the RFP, assessment, or internal review. Use the lowest substantiated score as the overall maturity rating unless a higher-risk connection type has been formally excluded from scope with documented justification.

For example, a Splunk search can provide repeatable evidence that invalid client certificates are being detected across reverse proxies:

index=nginx sourcetype=nginx:error
("SSL_do_handshake() failed" OR "client certificate verify error")
| stats count as failed_handshakes values(host) as affected_hosts by clientip
| sort - failed_handshakes

A score of 1.0–1.9 indicates Initial maturity; 2.0–2.9 indicates Repeatable; 3.0–3.9 indicates Defined; 4.0–4.4 indicates Managed; and 4.5–5.0 indicates Optimized. Retain the completed rubric, supporting log extracts, configuration baselines, procedures, and ticket samples as session-authenticity evidence logs for the proposal evidence library.

What commonly keeps organizations stuck at each maturity level?

• Initial: Teams equate encryption with authenticity and cannot show that both session endpoints validate who they are communicating with.
• Repeatable: Logs exist in separate consoles, but no owner can correlate an Entra ID sign-in, VPN connection, certificate event, and application session.
• Defined: Standards exist, but legacy applications receive indefinite exceptions for TLS settings, shared service accounts, or missing mutual TLS.
• Managed: Dashboards generate alerts, yet teams measure activity volume rather than control effectiveness, such as remediation time or certificate coverage.
• Optimized: Automation is introduced without validating its scope, leaving manually deployed appliances and third-party integrations outside the evidence stream.

What is a practical 90-day plan to advance one maturity level?

1. Days 1–30: Inventory in-scope communications paths: remote access, administrative access, web applications, APIs, cloud management interfaces, and device-to-device connections. Identify the current protocol, authentication method, certificate owner, log source, and CUI relevance for each path.
2. Days 31–60: Select the most material maturity gap and standardize it. Examples include enforcing TLS 1.2 or higher on all external services, forwarding GlobalProtect and Entra ID logs to Sentinel, or requiring mutual TLS for a high-value API integration. Update the system security plan and exception register.
3. Days 61–90: Demonstrate operation. Run failed-certificate and expired-certificate tests, verify SIEM alert creation, open and close remediation tickets, and assemble dated evidence. Score the rubric again and record the new baseline, remaining exceptions, accountable owners, and next-quarter target.

Before submitting the RFP response, convert the organization’s score, supporting artifacts, and 90-day improvement commitment into a concise SC.L2-3.13.15 evidence narrative that is accurate, traceable, and ready for evaluator review.