03.13.15 Session authenticity: requirements and evidence

What session authenticity means for CUI systems and why it is often missed

Requirement 03.13.15 asks the organization to protect the authenticity of its communications sessions. NIST judges this at the session level, not the packet level, so the question an assessor asks is whether an established session can be trusted to be the session its two ends actually negotiated. NIST's discussion names three threats the requirement addresses: adversary-in-the-middle attacks, session hijacking, and the insertion of false information into a session. The requirement is one determination statement in SP 800-171A Rev. 3, assessed by examining policy, procedures, design documentation, configuration settings and audit records, interviewing personnel with security responsibilities and system administrators, and testing the mechanisms that implement session authenticity.

The wording carries over from Rev. 2 requirement 3.13.15. NIST's change analysis traces the two versions together and classifies the change as editorial only, so an organization that has already mapped its Rev. 2 controls does not need to re-scope this requirement from scratch. The consequence matters more for DoD contractors. CMMC Level 2 uses the Rev. 2 numbering and assesses this requirement as SC.L2-3.13.15, worth 5 points under the 32 CFR 170.24 scoring methodology. Under 32 CFR 170.21, it cannot be carried on a plan of action and milestones to reach Conditional status, so an unmet session authenticity control counts against the score without a deferral path. Current DoW direction keeps DoD contractors assessed against Rev. 2 while CMMC Phase 2 is suspended, so the Rev. 2 wording governs the assessment even though the Rev. 3 text is the current NIST version.

This requirement is often missed because teams read it as a web application concern and assume that TLS on the public endpoint settles it. Session authenticity also covers internal sessions between administrative consoles, identity services, backup clients and management interfaces. Before an assessment, confirm with your assessor which systems in the CUI boundary carry sessions that need this protection, which mechanisms implement it, and where those settings are documented. Ask whether your evidence shows the mechanism working, not only that it is configured, because the test method looks for the implementation itself.

Which sessions, systems and third parties fall under session authenticity

Session authenticity applies wherever a communications session carries or controls CUI, so scoping starts by listing every session type that touches the CUI boundary. Each session type below is a decision that changes which mechanisms, configurations and records the organization must be able to show an assessor for 03.13.15.

User sessions into CUI systems

Every session where a person reaches a system holding CUI, including web applications, remote desktops and file portals, is in scope. Scoping here means listing each user-facing entry point and confirming how the session is protected against hijacking and insertion of false information, such as TLS with validated certificates and server-side session tokens. The evidence is the configuration of each entry point plus test results showing a tampered or replayed session is rejected. Confirm with your assessor whether they will sample entry points or require all of them.

Administrative sessions

Sessions opened by administrators for configuration, maintenance or troubleshooting usually carry the highest impact if hijacked, so they need their own inventory. Administrative access paths, including jump hosts, privileged consoles and nonlocal maintenance tools, should be listed separately from user sessions. The evidence changes because you must show how administrator sessions are authenticated, bound to a specific host and recorded in audit records, not only that the protocol is encrypted.

Service-to-service sessions

Applications, databases, message queues and automation jobs often talk to each other without a human present, and these sessions are easy to overlook. Scoping includes every internal call that moves CUI or controls a system that does, such as an API call from an application server to a database. Evidence usually means certificate issuance and rotation records, mutual authentication settings and a list of which services trust which certificate authority. Confirm how certificates are issued and renewed, because manual processes produce gaps an assessor will ask about.

Sessions through managed boundary devices

Traffic crossing external and key internal boundary points, including firewalls, VPN concentrators, proxies and load balancers, may be terminated and re-established by those devices. Scoping must state whether a device terminates the session, inspects it or passes it through, because that determines which side of the device carries the authenticity guarantee. The evidence includes the boundary device configuration, the certificates it presents and the logs showing that sessions are not downgraded or accepted from unexpected sources. Confirm this mapping against your boundary protection design under 03.13.01.

Sessions handled by external service providers

When a cloud provider, managed service or outsourced help desk opens sessions into CUI systems, those sessions remain part of your scope even though a third party runs them. Decide which provider sessions reach CUI, then review the contract and the provider's documentation for how it authenticates its staff and protects the session. The evidence you must hold is the provider's security documentation, your own configuration of the connection and any agreements on shared responsibility. Ask providers which session protections they can show you before you rely on them.

How an assessor tests session authenticity under SP 800-171A

This table compares the three assessment methods SP 800-171A Rev. 3 uses for the single determination statement under 03.13.15. Read each row as one method, what the assessor inspects, the evidence to prepare and the gaps that assessors most often record. The main takeaway is that the test method carries most of the weight, so a documented policy alone will not satisfy the requirement.

Method	What the assessor looks at	Evidence requested	Common findings
Examine	System and communications protection policy and procedures, plus the written procedures for session authenticity	Approved policy, a session authenticity procedure naming the owner, and review dates showing it is current	Procedure exists but does not describe how session authenticity is actually enforced on the system
Examine	System design documentation and system configuration settings that govern session protection	Architecture diagrams showing where session protection applies, and exported configuration for the relevant services	Design documents describe protection for some session types but omit others, such as internal administrative sessions
Examine	System audit records related to session authenticity	Sample logs showing session establishment, integrity-related failures and their handling	Logging is enabled but no one reviews failed or rejected session events
Interview	Personnel with information security responsibilities	Named owners who can explain how session authenticity is implemented and monitored	Staff describe the intent but cannot point to the configuration that enforces it
Interview	System administrators who configure and maintain the communications services	Walkthrough of how certificates, session tokens and transport protections are set up and renewed	Administrators rely on defaults that were never reviewed against the requirement
Test	Mechanisms that support or implement session authenticity	Live demonstration or test results showing that sessions are protected and that tampered or hijacked sessions are rejected	Test covers only the web front end, leaving internal service-to-service sessions untested

Implementing session authenticity in the order that passes assessment

This sequence turns 03.13.15 from a policy statement into mechanisms, configuration and evidence that an assessor can examine, interview against and test. The order matters because the mechanism choice depends on which sessions carry CUI, and the documentation depends on what was actually built.

Inventory the CUI session paths
Start by listing every communications session that carries or controls access to CUI: user sessions to web applications, administrative sessions, service-to-service calls, remote access, file transfers and sessions to external systems. Record the endpoints on each side, the protocol, and whether the session crosses a boundary. The owner is usually the system owner with the platform team, working from the system security plan boundary. The step is done when each path has a row in an inventory that the system security plan references, and any path left out has a written reason.
Define parameters and the authenticity mechanism per path
For each path, decide how the session will prove its authenticity and what values the organization assigns. NIST's Rev. 3 requirements use organization-defined parameters, and if no federal agency specifies them, the organization must set them. Typical choices include mutual TLS with certificate pinning or validation, signed session tokens, or session identifiers bound to the authenticated client. Each decision should name the parameter values, the certificate lifetimes or token lifetimes, and the reason. The output is a parameter register tied to the system security plan. Confirm with the contracting agency whether it has published values.
Issue and manage certificates or trust anchors
Establish the trust anchors that the chosen mechanism depends on. This can be an internal certificate authority, a managed PKI secrets engine that issues short-lived X.509 certificates, or an identity platform with an integrated CA. The platform team configures the root and intermediate hierarchy, issuance rules, renewal, revocation and key storage. Confirm that the cryptography meets the requirements in your contract, including FIPS-validated modules where your agreement calls for them. The output is an issued certificate set for each path, a revocation procedure, and a record of who can request and approve certificates.
Configure endpoints to reject unauthenticated sessions
Configure each endpoint so that sessions without valid authenticity evidence are refused, and sessions whose evidence does not match the expected identity or certificate are terminated rather than downgraded. Disable fallback paths that accept unauthenticated sessions, and record the configuration in the baseline managed under configuration management. Check that load balancers and proxies do not break the chain of authenticity. The output is exported configuration files, a list of disabled fallbacks, and screenshots or command output showing rejection behavior in a test environment.
Test the mechanism against adversary-in-the-middle scenarios
Test each path with the conditions the requirement targets: a session with a forged or expired certificate, a session replayed from another client, a hijacked session token, and an intermediary presenting its own certificate. The test should confirm that each attack is refused or terminated and that legitimate sessions still work. Record the test plan, the results and any remediation. Testing can be done by the internal team or a security testing provider, but the organization owns the results and decides what to fix. The output is a dated test record that an assessor can test against.
Write the procedures and design documentation
Document what the system does and how people operate it. The design documentation should show the session paths, the mechanism for each, the parameter values and the trust anchors. The procedures should cover certificate issuance, renewal, revocation, incident handling for a suspected hijack, and periodic review of configuration. Keep the documents under version control and link them to the system security plan. The step is complete when an administrator unfamiliar with the build could reproduce the configuration from the documents, and an assessor examining them finds the decisions traceable to the requirement and the test record.

Which evidence passes an examine, interview and test for 03.13.15

SP 800-171A Rev. 3 assesses 03.13.15 with one determination statement, so an assessor will examine documents, interview the people who run the sessions, and test the mechanism itself. The cards below cover the artifacts that usually satisfy those three methods, and the routine that keeps each one accurate between assessments.

Session authenticity procedures

Write down how the organization protects session authenticity: which session types are in scope (web sessions, administrative consoles, API calls, VPN and remote maintenance), which mechanisms apply to each, and who approves exceptions. The examine method starts here, so the procedure should name the systems and roles, not just restate the requirement. Check that it matches the system security plan and that the version and owner are recorded. Review it whenever a new session path or protocol is added.

System design documentation of authentication points

Diagrams and narratives should show where each session is established, where it is authenticated, and where the session tokens or keys live. Include load balancers, reverse proxies and TLS termination points, because an assessor will ask where trust is anchored. Mark which components enforce integrity and which only pass traffic through. Update the diagrams with every architecture change, and tie each change to a ticket so the document history can be shown.

Configuration settings for certificates and session protections

Export the live settings that enforce session authenticity: TLS versions and cipher suites, certificate lifetimes and revocation checks, session token lifetimes, and cookie or token binding options. Store exports from the running systems, not from memory of the build guide, and record the date of each export. Compare them against the hardening baseline to catch drift. A reviewer can then match the settings to the procedure and the design documents.

Test results showing rejected spoofed or altered sessions

The test method requires evidence that the mechanism works, so run controlled tests that present a forged certificate, a replayed or tampered session token, and a session moved to a different client. Record the input, the expected result, the observed rejection and the log entry it produced. Keep the test scripts under version control so the same test can be rerun before each assessment. Retest after any change to the TLS stack or identity provider.

Audit records of authentication and session failures

Pull logs showing failed certificate validation, rejected session tokens and session terminations triggered by integrity checks. Confirm that the logs carry timestamps, source addresses and the account or device identifier, and that they are forwarded to the central store. An assessor reviewing examine objects will look for records that show the protection operating over time, not only during the test. Sample the logs on a fixed schedule and keep the sampling record.

Interview-ready ownership records

Maintain a current register that names the owner of each session mechanism, the administrator who changes its settings, and the person who approves exceptions. Interviews with personnel with security responsibilities and system administrators test whether these people can explain the mechanism in their own words. Confirm each named person can describe the test results and the procedure. Review the register at each staffing change and after each assessment.

Which self-hosted open-source tools support session authenticity evidence

FreeIPA is an open-source identity management system (GPL-3.0-or-later) that bundles directory, Kerberos and certificate services. Its integrated certificate authority is based on Dogtag and handles issuing and managing certificates for hosts and services. For 03.13.15, that matters because certificates are one of the mechanisms that let endpoints verify who they are talking to, which supports defenses against adversary-in-the-middle attacks and session hijacking.

Certificate issuance: The integrated Dogtag-based CA issues and tracks certificates, giving you an inventory and issuance records to examine.
Identity binding: Host and service principals can be tied to certificates, so server identity can be checked during session setup.
Revocation records: Revocation and renewal history can be shown to assessors as evidence of managed certificate lifecycles.
What you still configure: Session-level TLS settings, cipher and protocol choices, certificate validation in each application, and the policy that requires clients to validate peers.
License caveat: GPL-3.0-or-later obligations apply if you modify and distribute the software. Confirm how your licensing counsel treats your deployment model.

Confirm with the FreeIPA project whether a given session-level feature is supported in your release before you cite it. Your system design documentation should show which applications actually validate the certificates FreeIPA issues.

What meeting session authenticity costs in money and effort

This table breaks down the cost components of protecting session authenticity under 03.13.15, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to reduce it. No prices are stated because none are supplied, so use the table to structure quote requests and internal budgets.

Cost component	Who is paid or who carries it	One-time or recurring	Drivers and how to reduce it
Tooling and licenses	Software vendor or none if self-hosted open source	Recurring if licensed, one-time if deployed	Commercial session or PKI products add license fees, while self-hosted options such as FreeIPA (GPL-3.0-or-later) and OpenBao (MPL-2.0) remove license spend but still need hosting and staff time. Confirm each product's license terms before adoption.
Engineering design and configuration	Internal engineers or an implementation partner under a fixed-scope agreement	One-time, with later changes recurring	Drivers include the number of session types (web, API, admin, remote maintenance), existing identity infrastructure and the depth of the system security plan. Reduce it by mapping session paths once and reusing a standard pattern across systems. Ask for a written list of deliverables.
Certificate operations and renewal	Internal platform or security team, with automation tooling	Recurring	Manual certificate requests, key generation and renewal tracking grow with the number of services. Dynamic issuance, such as the OpenBao PKI secrets engine, reduces manual steps. Ask the quote to state who handles revocation and how renewal failures are alerted.
Evidence upkeep	Internal compliance or security staff	Recurring	Assessors look for configuration settings, design documentation and audit records tied to session authenticity. Keeping these current after each change is the main ongoing effort. Reduce it by generating configuration exports and logs automatically and storing them with change records.
External testing or review	Independent testing firm or consultant, scoped in writing	Recurring at each test cycle	Scope depends on how many session mechanisms are tested for adversary-in-the-middle and hijacking weaknesses. Ask for the test methods, the systems in scope and whether retests are included.
Independent assessment sampling	Assessor or certification body, selected by the sponsoring agency or customer	Recurring at each assessment	Assessors examine policy, system design, configuration and audit records and interview administrators. Costs rise when evidence is scattered across tools or undocumented. Keep one evidence index for this requirement so sampling takes less time.
Research and assessment methods	Internal staff reviewing NIST documents	One-time, then periodic	The SP 800-171A Rev. 3 assessment for 03.13.15 uses one determination statement with examine, interview and test methods. Reading it against your design early avoids rework later.

Who does what for 03.13.15: your team, a partner and the assessor

Your organization owns requirement 03.13.15 in full. The control belongs to you even when a partner builds the systems that support it, and the contracting federal agency holds you accountable for how it is applied to your nonfederal system. Decisions that only you can make include which communications sessions carry CUI, which session authenticity mechanisms you accept as adequate, and how any organization-defined parameters are set where the contract does not specify them.

Policy and procedures: Maintain the system and communications protection policy and the procedures for session authenticity, since these are the first documents an assessor will examine.
Scope decisions: Identify which applications, portals, admin consoles and file-sharing services carry CUI sessions and confirm they sit inside the assessed boundary.
Configuration ownership: Approve the session settings, certificate lifetimes and trust anchors, and keep them under change control.
Operational records: Keep system audit records of certificate issuance, renewal and session-related failures, and review them.
Staff roles: Name the people who answer assessor interviews about session protection, including system administrators.

Before accepting any partner's evidence, confirm that your own staff can explain each session protection choice without reading the vendor documentation.

Where session authenticity gaps usually appear and how to close them

Session authenticity gaps tend to sit at the edges of a program: trust that stops at the perimeter, procedures that exist only in someone's head, and evidence that was never collected. The cards below pair each gap with the closing action an assessor will expect to see, so the team can check its own environment before an examine, interview or test pass.

Trust stops at the perimeter

Certificates and mutual authentication often cover the internet-facing load balancer while traffic between application tiers, databases and internal APIs runs unauthenticated. Session authenticity is assessed at the session level, so an adversary who reaches the internal network can still hijack or inject into a session. Check which internal sessions carry CUI and confirm each one has an authenticated endpoint on both sides.

No documented session authenticity procedure

The examine method looks for procedures for session authenticity in the system and communications protection policy. Many organizations have encryption standards but no written procedure that names the session types, the mechanisms used and the owner who approves exceptions. Write the procedure against the systems in the system security plan, and tie each session type to the mechanism that protects it.

Unclear certificate issuance ownership

When no one owns certificate issuance, renewal and revocation, sessions fail silently or teams bypass checks with self-signed certificates. Assign a named owner for the internal certificate authority, record who can request certificates, and document renewal and revocation steps. Interviews with system administrators will test whether this ownership is understood in practice, not just written down.

Undefined session parameters

Rev. 3 uses organization-defined parameters, and a nonfederal organization must assign values where the federal agency has not. For session authenticity, the lifetime of issued certificates, the trust chain accepted, and the conditions that force re-authentication are the values an assessor will look for. Set these values, record their rationale and confirm with the contracting agency whether it has specified any.

Missing test evidence

The test method for 03.13.15 requires mechanisms that support or implement session authenticity to be exercised, not just described. A configuration screenshot does not show that a rejected certificate actually ends a session. Keep records of handshake tests, rejected-certificate tests and session-hijack simulations, dated and tied to the system version under assessment.

Assuming encryption alone satisfies the requirement

Encryption protects confidentiality, but it does not by itself prove that each session is authenticated to the right peer. A TLS session can be encrypted to an attacker if the client does not validate the server certificate. Verify that clients validate certificate chains and hostnames, and that the design documentation explains how authenticity, not only confidentiality, is established for each session.

Questions buyers ask about 03.13.15 cost, effort and outside help

What does the internal team have to supply for 03.13.15?

Your team owns the control, so it must supply the people, decisions and records that show session authenticity is in place. Expect the work to need someone who knows how your web applications, APIs and identity services establish sessions, someone who owns the certificate and key lifecycle, and a system administrator who can confirm configuration settings. Assessors will also look for the system and communications protection policy, procedures for session authenticity, design documentation and audit records, so the internal team must be able to produce and maintain those. Ask any partner to list these roles in the written scope so you know which hours sit with you.

Can we implement 03.13.15 in-house with open-source tools?

Often yes, provided your team has the skills to design and operate the mechanisms. Open-source components can support the control. FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates, and the OpenBao PKI secrets engine issues dynamic X.509 certificates so services do not need manual key and CSR handling. Whether these fit your architecture depends on how your sessions are built, so confirm during design that the chosen mechanisms actually protect sessions against adversary-in-the-middle attacks and hijacking, not only individual packets. Your assessor will test the mechanism, not the tool name.

How long does it take to plan and implement 03.13.15?

No researched duration is available for this control, so treat any timeline you receive as an estimate to be confirmed in writing. Timing is driven by how many systems establish sessions, whether certificate infrastructure already exists, how many applications need changes, and how much documentation the assessment will require. Ask for a timeline that lists each system in scope, the testing you expect to run, and the evidence that will be produced. Fixed-scope engagements, which are the usual model at DeployOpen, are agreed in writing before work starts, so the scope document is where timing should be settled.

What drives the cost of 03.13.15 up or down?

The main cost drivers are the number of session-establishing systems, the state of your existing certificate and identity infrastructure, and the amount of application code that must change. Costs usually fall into three groups: internal staff time, engineering and configuration work by any implementation partner, and independent assessment fees paid to an assessor or certification body. The first two are largely one-time, while certificate renewal, monitoring and retention of evidence recur. When requesting a quote, ask for the cost split by these groups, the systems covered, which items are one-time versus recurring, and what changes would move the price.

Can the assessor also implement 03.13.15 for us?

No. An assessor or certification body tests your implementation and issues the findings or report, so it cannot also build the control without compromising its independence. An implementation partner such as DeployOpen can plan, configure, document and prepare evidence for session authenticity, but it does not issue assessment results. Keep the two roles separate in your contracts and ask each party to state in writing what it delivers and what it does not. Your organization remains responsible for the control and its operation.

Does 03.13.15 differ between NIST SP 800-171 Rev. 2 and Rev. 3?

In substance, no. The Rev. 2 to Rev. 3 change analysis traces 03.13.15 to Rev. 2 requirement 3.13.15 and classifies the change as not significant, editorial only. The Rev. 3 requirement still protects the authenticity of communications sessions, and NIST's discussion describes the same threats: adversary-in-the-middle attacks, session hijacking and insertion of false information. The practical difference is the assessment context. Rev. 3 uses the 03.13.15 determination statement in SP 800-171A Rev. 3, while CMMC Level 2 and current DoD contracts still reference Rev. 2 numbering, so confirm which version your contract names before preparing evidence.

What happens if 03.13.15 is not fully met at assessment?

Under the CMMC scoring methodology, 3.13.15 is worth 5 points, and 32 CFR 170.21 does not allow it on a plan of action and milestones for Conditional status. That means a gap in session authenticity cannot be deferred on a POA&M if you are seeking Conditional status under CMMC Level 2. Plan to close this requirement before the assessment, and ask any partner to test the mechanism during implementation so gaps surface early. Confirm the current status of these rules with your contracting office, since DoD guidance on CMMC phasing has been changing.

How DeployOpen scopes, implements and prepares evidence for 03.13.15

DeployOpen plans and implements the technical controls behind 03.13.15 Session authenticity inside the client's own infrastructure, then prepares the configuration records and evidence an assessor will examine. The organization owns the control and its risk decisions, and only an independent assessor can judge whether the requirement is met.

How we scope

The written scope names the systems, session paths and services where session authenticity must hold for CUI.
We confirm which internal and external sessions carry CUI and which mechanisms currently protect them.
The scope lists the evidence sources, such as policy, design documents, configuration settings and audit records, agreed before work starts.

How we build

We configure certificate issuance and session protection so service-to-service communications are authenticated at the session level.
Certificate authorities, such as those in FreeIPA or OpenBao, are set up inside the client's environment with documented issuance policies.
We test that adversary-in-the-middle, session hijacking and false-information insertion scenarios are blocked or detected by the configured mechanisms.

How we hand over

Deliverables include the configuration baseline, design documentation and a record of the session authenticity tests performed.
We map each artifact to the examine, interview and test objects in SP 800-171A Rev. 3 so the assessor can trace the evidence.
Runbooks explain how administrators maintain certificates, rotate keys and review session audit records after handover.

How we support

Fixed-scope engagements end with written deliverables, and any remaining gaps are listed for the client to decide on.
Ongoing support, upgrades and continuous testing of session controls are available as a retainer.
Before any assessment, confirm with your assessor which evidence format and retention period they expect for 03.13.15.