SC.L2-3.13.15 Communications authenticity: evidence guide

What SC.L2-3.13.15 communications authenticity requires in CMMC Level 2

SC.L2-3.13.15 asks a defense contractor to protect the authenticity of its communications sessions, so that each end of a session can trust the identity of the other. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.13.15, and NIST SP 800-171A assesses it with a single objective: the authenticity of communications sessions is protected. The requirement is narrow in wording but broad in reach, because every system that accepts or initiates a session, from a web application and an API to a database connection and a machine-to-machine link, is in scope for the question an assessor will ask: how does this system know who it is talking to, and how does the other side know the same about it?

The risk it addresses is session hijacking and impersonation. An attacker who takes over an established session, or who poses as a peer service, a device or a server that the system depends on, can read CUI, inject commands or change data without ever touching a stored credential. The requirement carries 5 points in the CMMC scoring methodology, which means a NOT MET finding subtracts 5 from the maximum score of 110. Because it is worth more than 1 point, it cannot be placed on a plan of action and milestones under 32 CFR 170.21, so the reader must treat it as a gate: the requirement has to be fully MET, with evidence in final form, before the organization can reach Conditional or Final Level 2 status.

It is hard to satisfy for a practical reason. Session authenticity is rarely implemented in one place. It is usually provided by the security protocol enforced for each session, and the CMMC Assessment Guide notes that mutual authentication at session setup is a common approach, especially between devices. Each protocol, service and legacy connection can behave differently, so the first task is an inventory of every session path that carries CUI, including internal service-to-service traffic. Confirm with your assessor which mechanisms they expect to test and what evidence they will sample, and document the protocol and authentication settings for each path before the assessment begins.

Which systems and sessions fall under SC.L2-3.13.15 scope

Session authenticity applies wherever CUI moves between two ends that must trust each other. Scoping means listing every such session, deciding which ones carry or control CUI, and then recording which parties are responsible for each one. The cards below follow the scope boundary from the outside in.

CUI system sessions

Start with the systems inside the CUI boundary, including the file stores, email, collaboration tools and line-of-business applications where CUI is created, processed or stored. Each user session that reaches these systems needs an authenticated, protected channel, and assessors will ask which protocol and configuration enforce it. Confirm the session protocol for each application, and record any application that cannot negotiate a protected session as a scoping exception to resolve before assessment.

Internal service-to-service sessions

Application tiers, APIs, message queues and databases that exchange CUI inside the environment are often the largest group of sessions and the easiest to miss. Each service should prove its identity to the peer it calls, usually through mutual authentication at connection setup. Inventory these flows from architecture diagrams and live traffic, not from memory, because undocumented service calls are where authenticity gaps tend to hide.

Administrative sessions

Administrators who manage CUI systems create sessions that can change security settings, read logs and reach privileged functions. These sessions carry higher risk than user sessions and deserve explicit scoping, including jump hosts, console access, remote management interfaces and vendor support tunnels. Confirm that each administrative path authenticates both the administrator's endpoint and the managed system, and that the path is listed in the system security plan.

Device-to-device links

Network devices, storage arrays, printers, sensors and endpoints may exchange CUI or management traffic directly with one another. Device authenticity is often provided by certificates or pre-shared keys configured at the device level, so each link needs an owner and a documented trust method. Include devices that connect to the CUI environment for backup, replication or telemetry, since these links can carry CUI without appearing in application diagrams.

Third-party and external connections

Connections to subcontractors, managed service providers, cloud service providers and external collaboration platforms are in scope when CUI crosses them. The organization is responsible for the sessions it controls, while provider-side sessions depend on the contract and the provider's documented security. Ask each provider to show how its sessions to your environment are authenticated, and record the answers in the responsibility matrix so the assessment does not depend on assumptions.

Enclave boundaries and provider sessions

Scope changes the work most at the boundary. A dedicated enclave with its own identity provider, certificate authority and gateway limits the number of sessions to authenticate, but every session crossing into it must still be protected. If a cloud service provider hosts CUI, determine whether its sessions are inherited through a provider attestation or must be evidenced directly. Confirm the boundary decision with the assessor before building the evidence set.

How session authenticity is usually implemented

Session authenticity is usually delivered by the security protocol that governs each session, not by a separate feature. The CMMC Assessment Guide for Level 2 describes the common pattern: a mutual authentication handshake when the session is established, which is especially relevant between devices. In that handshake each end presents credentials and verifies the other's identity before any application data moves. An assessor testing SC.L2-3.13.15 will therefore look first at which protocol the system enforces for its sessions, whether that protocol requires authentication in both directions, and whether a client or service that cannot prove its identity is refused rather than quietly downgraded.

Encryption alone does not meet this objective. SC.L2-3.13.8 and SC.L2-3.13.11 cover confidentiality of CUI in transit and the use of FIPS-validated cryptography, so a tunnel can be fully encrypted and still connect to an impostor if neither side verified the other. Authenticity is the separate question of whether the peer at the far end is the one it claims to be. Organizations should confirm that each protected interface, including service-to-service and device-to-server links, uses certificate or key-based mutual authentication, and that the trust anchors and certificate chains behind it are documented. The mapped control reference in NIST SP 800-171 Rev. 2 Appendix D is SP 800-53 Rev. 4 control SC-23 (Session Authenticity), which is a useful cross-reference when the same system is assessed against other frameworks.

Plan the work around certificate issuance and renewal, since that is where most of the recurring effort sits. Internal certificate authorities such as the one integrated in FreeIPA, or PKI secrets engines such as the one in OpenBao, can issue short-lived X.509 certificates to services so they do not depend on manual key and signing requests. The organization still owns the decisions: which authority is trusted, how certificate lifetimes and revocation are set, and who may request certificates. Ask any implementation partner to show the configuration, the issuance log and the procedure for revoking a compromised identity, because an assessor will expect that evidence to exist in final form before the requirement can be marked MET.

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

This table compares what an assessor does, what they ask you to produce, and where organizations usually fall short when testing SC.L2-3.13.15. Read it as a checklist: the single objective must be met in full, and each row shows how the evidence is tested.

Assessment step	Evidence requested	Common findings
Confirm the single objective	The system security plan description of how session authenticity is protected for each session type in scope	Plan describes encryption in general terms but does not name the sessions or the authentication step
Identify communications sessions in scope	Inventory of session types crossing the system boundary, including device-to-device, user-to-application and service-to-service traffic	Service accounts, API calls and internal server links are left out of the inventory
Test the mechanisms that implement authenticity	Configuration of the protocol enforced for each session, such as TLS settings, certificate validation and mutual authentication handshake settings	Clients accept any certificate, or the server does not require client certificates where mutual authentication is documented
Review procedures and audit records	Procedures that describe session establishment and logs showing authentication success and failure for sessions	Logs are not retained, or failed session authentication events are not recorded or reviewed
Sample sessions and observe behavior	Live or recorded demonstration of a session being established and rejected when the peer identity is invalid	Demonstration covers only the happy path and never shows a rejected untrusted peer
Check certificate and key lifecycle	Records showing who issues certificates, how they are renewed and revoked, and where private keys are held	Expired or self-signed certificates remain in use, or revocation is not checked
Decide the result	Final-form evidence for every in-scope session type, with no draft procedures or unsigned plans	Requirement is not MET because one session type lacks final evidence, which blocks Conditional or Final Level 2 status

Steps to implement session authenticity for CUI systems

This sequence takes a CUI environment from an inventory of its communications sessions to a tested, documented state in which each end of a session can verify the identity of the other. Each step produces an artifact an assessor can review against SC.L2-3.13.15.

Inventory CUI sessions and their peers
The system owner, with input from network and application teams, lists every session that carries or controls CUI. The list covers user-to-application sessions, service-to-service calls, administrative connections, backup and replication links, and device-to-device traffic, and names the two endpoints in each. Done means the inventory is reviewed, each session has an owner, and gaps between the inventory and the system security plan boundary are recorded for correction.
Choose the protocol and authentication mode
For each session type, the security architect selects the security protocol that will carry it and decides whether authentication is one-way (server only) or mutual (both ends present identities). Mutual authentication is the usual choice for device-to-device and service-to-service sessions. The decision is written down per session type, with the protocol version and approved cipher configuration, so an assessor can trace each session to a specific design choice.
Issue and manage session identities
The identity owner establishes an internal certificate authority or a managed identity service, issues certificates or keys to each endpoint, and sets lifetimes, renewal and revocation procedures. Tools such as FreeIPA, which includes an integrated certificate authority based on Dogtag, or the OpenBao PKI secrets engine, which issues X.509 certificates to services on request, are options to evaluate, but the team should confirm each product's fit for its environment. Done means every endpoint in the inventory has a documented identity, a named issuer, and a revocation path tested at least once.
Enforce the protocol through configuration
The platform engineer configures each endpoint and gateway to require the chosen protocol and authentication mode, and to reject sessions that do not present a valid peer identity. Configuration files, policy objects and infrastructure-as-code definitions are version-controlled and reviewed through change control. Done means the configuration baselines are stored with their change history, and the settings that enforce mutual authentication are visible in a configuration export that can be shown to an assessor.
Validate with test sessions
The security team runs test sessions for each session type and attempts failure cases, such as a connection from an endpoint with no certificate, an expired identity, or an identity signed by an untrusted authority. Each test records whether the session was established or refused and whether the logs captured the event. Done means every test has a recorded result, every failed control is either fixed or documented on the plan of action, and the test is repeatable after configuration changes.
Record the output of each step
The compliance lead assembles the inventory, protocol decisions, identity records, configuration exports, test results and audit records into a single evidence set for SC.L2-3.13.15. Each artifact is dated, versioned and approved by its owner, and the system security plan is updated to describe how session authenticity is implemented. Done means the evidence is in final form, not drafts, and an assessor can trace a session from the inventory to a configuration setting and a passing test.

Evidence that passes an assessment for session authenticity

An assessor testing SC.L2-3.13.15 looks for proof that the mechanism works in practice, not only that it was designed. The cards below cover the artifacts that usually carry that proof, and each one needs a review rhythm so it still matches the live system when the assessment happens.

Protocol and cipher configurations

Export the effective settings for every protocol that establishes sessions, including TLS versions, cipher suites, and certificate validation options on servers and clients. Assessors compare these exports with the system security plan and check that the mutual authentication requirement is enforced, not merely supported. Keep the configuration files under version control so each change has a reviewer and a date. Recheck the exports after every patch cycle and every change to a load balancer, proxy or VPN gateway, because a single default override can quietly disable client certificate checks.

Certificate issuance and revocation records

Mutual authentication depends on certificates that identify each end, so assessors ask who issued them, to which identity, and how they are withdrawn. Keep the certificate authority's issuance log, the approval trail for each certificate, and revocation records for retired devices and departed staff. An internal certificate authority such as the one included in FreeIPA, or a dynamic issuance engine such as the OpenBao PKI secrets engine, can produce these records automatically. Confirm that revocation status is actually checked by the relying services, since a revoked certificate that is still accepted is a finding.

Mutual authentication test results

Test results show that a session is refused when one end cannot present a valid identity. Run negative tests with an expired certificate, a revoked certificate, an untrusted issuer, and a device with no certificate, then record the refused handshake and the reason. Keep the test scripts, the target version of each system, and the results together in one dated package. Assessors value tests they can rerun, so ask the tester to document the exact steps and to repeat them after material changes to the network path or the protocol stack.

Audit logs of authenticated session establishment

Logs show the assessment objective being met in operation. Each session start should record both identities, the authentication result, the time, and the connection source, and each refused handshake should also be logged. Confirm that logs from load balancers, application servers and identity services reach the central log store and that the timestamps are synchronized. Review a sample of sessions each month for failed or unusual authentications, and record the review, because the assessor will ask who reads these logs and what they do when a session fails.

System security plan describing the mechanism

The system security plan must name the mechanism that protects session authenticity, the components that enforce it, and the party responsible for each one. Describe the handshake in plain terms, list the certificate authority and its trust chain, and state how identities are issued and retired. Link each statement to a configuration file, log source or test result that proves it. Update the plan whenever a protocol, gateway or certificate authority changes, and record the review date at the top of the document so the assessor can see that the plan reflects the current system.

Keeping evidence current between assessments

Evidence goes stale when systems change, so assign an owner for each artifact and set a recurring review in the change calendar. Tie the configuration export, certificate inventory and negative test run to change tickets, so any gateway upgrade or certificate authority change triggers a fresh capture. Store evidence in a read-only location with retention long enough to cover the assessment window, and confirm the retention period against your contract and internal policy. Ask any implementation partner to document this routine in writing as part of the scope.

How self-hosted open-source tools can produce session authenticity evidence

Session authenticity under SC.L2-3.13.15 depends on each end of a connection holding an identity that the other end can verify, and the self-hosted tools most often used for that are a certificate authority and a secrets engine that issues short-lived certificates. FreeIPA, licensed under GPL-3.0-or-later, includes an integrated certificate authority based on Dogtag for issuing and managing certificates for hosts and services, which lets an organization run its own internal trust chain inside its boundary. OpenBao, licensed under MPL-2.0, has a PKI secrets engine that issues dynamic X.509 certificates, so a service requests a certificate and receives one without someone generating a key and certificate signing request by hand and waiting for a CA to sign it. Either tool can supply the identities used in a mutual authentication handshake, but neither one configures that handshake for you.

The evidence an assessor will look for is the mechanism itself: which identities exist, how they were issued, how long they last, and whether the protocol that uses them rejects a peer that cannot present a valid certificate. Useful artifacts include the certificate authority configuration, the issuance and revocation logs, the role or policy that limits which services can request which certificates, and captured handshake or protocol settings showing client authentication is required. Assessors may also test that an unauthenticated or wrongly identified peer is refused, so a test of that refusal is worth keeping. Before relying on either tool, confirm with the vendor or your own engineers that the certificate lifetimes, trust roots, renewal process and revocation handling match your environment and your system security plan, and that any FIPS-validated cryptography requirements for the modules in use are addressed separately under the relevant requirements.

Plan for the work that surrounds these tools rather than assuming the tools finish it. Someone must decide which hosts, services and clients receive identities, who approves changes to the certificate authority, how private keys are protected, and how rotation is scheduled and tested without interrupting sessions. An implementation partner can prepare the configuration, document the trust model and collect the evidence, but the organization owns the decisions and the resulting control, and only an independent assessor can judge whether the requirement is MET. Ask any partner to show how each identity is issued, renewed and retired, and to demonstrate the refusal test before the assessment begins.

What meeting SC.L2-3.13.15 costs in money and effort

This table breaks down the cost components of meeting SC.L2-3.13.15 by who is paid, whether each cost is one-time or recurring, what drives it, and how to keep it down. Use it to structure a quote request, since no price or duration is supplied for this requirement and the real figures depend on your architecture and scope.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Protocol and identity design (engineering time)	One-time, with revisits when systems change	Number of session types, device classes and enclaves that need mutual authentication; whether legacy protocols must be retired	Standardize on one secure protocol profile for internal sessions and document it once in the system security plan
Certificate authority and PKI tooling	Mostly one-time setup, plus recurring operation	Whether an internal CA already exists; choice of open-source CA such as FreeIPA's Dogtag-based CA or OpenBao's PKI secrets engine; hosting and staffing	Open-source software license cost can be zero, so budget mainly for the staff time and infrastructure needed to run it
Certificate lifecycle upkeep	Recurring	Number of services and devices holding certificates; issuance frequency; renewal, revocation and key rotation procedures	Automate issuance and renewal so certificates are not created by hand, and keep logs of issuance and revocation events
Integration and testing of session authentication	One-time, plus regression testing after changes	Number of applications, APIs and enclave boundaries; third-party or vendor-managed systems that cannot be reconfigured	Test mutual authentication in a staging environment first and reuse test scripts for each release
External testing or independent review	Optional, usually per engagement	Scope of the review, whether it covers only configuration or also protocol behavior, and the depth of testing requested	Agree the scope in writing before work starts and limit it to the session authentication mechanisms in use
Assessor sampling and evidence preparation	Recurring at each assessment	How many sessions, systems and log records the assessor samples; whether evidence is in final form	Keep configuration baselines, handshake settings and audit records organized so an assessor can sample them quickly
Ongoing support or retainer	Recurring	Frequency of upgrades, certificate changes and new integrations; response expectations	Ask for a fixed-scope quote with defined upgrade and support boundaries

Who owns session authenticity: your team, a partner and the assessor

Your organization owns SC.L2-3.13.15. That means deciding which communications sessions carry CUI, which authentication mechanism protects each session type, and who accepts the residual risk when a mechanism is weaker than the rest of the environment. The requirement is assessed against the single objective in NIST SP 800-171A, so the assessor will ask whether the authenticity of communications sessions is protected in your actual system, not whether a policy says it should be.

Scope decisions: List the session types that carry or control access to CUI, including service-to-service calls, administrative sessions and remote user connections.
Mechanism selection: Choose how each session establishes trust, such as a mutual authentication handshake or a protocol enforced for the session, and record why.
Risk acceptance: Name the accountable owner for any exception, and keep that decision in writing.
Operating records: Keep configuration baselines, change records and audit records that show the mechanism stayed in place over time.
Staff readiness: Make sure administrators can explain how session trust works and where it is configured.

Before assessment, confirm that someone inside your organization can walk an assessor through each session type and point to the evidence for it.

Common gaps that cause SC.L2-3.13.15 to be NOT MET

SC.L2-3.13.15 is a 5-point requirement that cannot go on a POA&M, so a single gap in session authenticity can keep an organization from reaching Conditional or Final Level 2 status. The gaps below recur because encryption is often mistaken for authentication, service traffic is rarely written down, and evidence is gathered too late. Each card names the gap and the closure step an assessor will expect to see.

One-way TLS mistaken for session authentication

Many teams see a padlock in the browser and assume the session is authenticated. Standard TLS usually proves only the server's identity to the client, so the server may not know which device or service is on the other end. Where the session must prove both ends, the closure step is to enforce mutual authentication, with client certificates or an equivalent handshake, on every session in scope. Check the protocol configuration on each endpoint, not just the load balancer, and confirm that a connection without a valid client identity is refused.

Undocumented service-to-service sessions

Application tiers, APIs, databases, backup agents and monitoring tools often open sessions to each other without anyone recording how those sessions are authenticated. An assessor who samples a session cannot find the mechanism, so the objective is not demonstrated. Closure means inventorying service-to-service paths, naming the protocol and identity method for each, and tying each path to a documented owner. Illustrative example: a reporting database that accepts a shared password from three applications should be listed with its authentication method and planned replacement.

Expired or unmanaged certificates

Mutual authentication depends on certificates that are issued, renewed and revoked on schedule. Expired certificates break sessions, and teams often respond by disabling client authentication, which quietly removes the control. Closure requires a certificate inventory with issuer, subject, expiry and owner, automated or tracked renewal, and a documented revocation process. Ask whether an internal certificate authority is in scope and how its issuance records are retained. A certificate that no one can account for is treated as an unmanaged identity.

Draft-only or incomplete evidence

Evidence in draft form does not satisfy the assessment. Diagrams of the session architecture that are marked as drafts, configuration screenshots without dates, or policies that were never approved will not show that the mechanism operates. Under the CMMC rules, a requirement is MET only when the evidence is in final form. Closure means finalizing the session architecture document, approving the related standard, and retaining the approval record, so the assessor can trace the requirement to a current, signed version.

Missing configuration proof

A statement that sessions are authenticated is not enough. Assessors may test the mechanisms that implement session authenticity, so they will ask to see the live configuration and the logs that show it working. Gaps appear when settings exist only in a deployment script, when a legacy endpoint still accepts unauthenticated sessions, or when no audit record shows a rejected connection. Closure means exporting the effective configuration from each in-scope endpoint, retaining handshake and rejection logs, and walking an assessor through a test session from start to finish.

Authentication gaps on remote and vendor paths

Sessions that leave the organization, such as vendor support tunnels, remote administration and file exchanges with subcontractors, are often configured outside the team that owns the main system. These paths may use a shared account or a protocol that does not verify the remote party. Closure requires listing every external session path that carries CUI or controls CUI systems, confirming that each one authenticates both ends, and recording the vendor's method in the system security plan so the boundary is consistent.

How much effort and outside help does SC.L2-3.13.15 need?

Can a defense contractor meet SC.L2-3.13.15 in-house?

Yes, a contractor with staff who run its network, identity and certificate systems can often meet SC.L2-3.13.15 without outside help. The organization owns the control, so it must be able to show how sessions between systems and devices are authenticated at each end and keep that evidence in final form. Outside help is optional. It becomes more useful when the team lacks experience with mutual authentication, certificate lifecycle management or assessment-ready documentation, or when it needs an independent view of the design before the assessor arrives.

What drives the effort for SC.L2-3.13.15?

Effort depends mostly on how many session types the system uses and how much of their authentication is already built in. The main drivers are:

The number of communication paths between devices, services and users that carry CUI, and whether each one already uses a protocol that authenticates both ends.
The state of the certificate or identity infrastructure that issues credentials, including whether it is documented, monitored and tied to an owner.
The number of legacy or vendor-managed components that cannot present or validate certificates.
How well the existing system security plan describes the mechanism and how the evidence is collected.

A smaller, well-documented environment with a single identity source usually takes less work to evidence than a mixed estate.

Can SC.L2-3.13.15 be placed on a POA&M?

No. SC.L2-3.13.15 is a 5-point requirement, and the CMMC rule does not allow requirements worth more than 1 point on a plan of action and milestones. It must be MET before the organization can reach Conditional or Final Level 2 status, so any gap has to be closed before the assessment. Plan the mechanism, the configuration and the evidence early, and confirm the current rule text in the eCFR version of 32 CFR Part 170 with your contracting officer or counsel.

What does the work need from our staff?

The work needs several roles working together, and most of them already exist in a defense contractor. A network or infrastructure engineer must know which sessions cross boundaries and how they are established. An identity or systems administrator must own the certificate and authentication services. A security lead must map the mechanisms to the system security plan and decide what evidence to keep. Someone must also be able to explain the design to an assessor and show that configurations match the documentation. Staff time is usually concentrated in discovery, configuration review and evidence collection rather than in ongoing operation.

How long does it take to prepare for SC.L2-3.13.15?

Preparation time depends on the factors above, and no duration is set by the requirement itself, so ask any vendor or consultant for a schedule built from your own inventory. Timing also depends on federal status. On 13 July 2026 the Department of War suspended CMMC Phase II, and its announcement describes the suspension and a review period. Confirm the current assessment schedule on the DoW CIO About CMMC page and in your contract terms before setting internal deadlines.

Will an assessor accept open-source tooling as evidence for SC.L2-3.13.15?

An assessor accepts evidence based on whether the mechanism works and is documented, not on the license of the software that produces it. Assessors may test the mechanisms that implement session authenticity, so open-source components must show a working configuration, such as a mutual authentication handshake enforced for the session, along with logs and records of certificate issuance. For example, FreeIPA includes an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine issues dynamic X.509 certificates. Both can supply configuration exports and issuance records, but the organization must confirm that the chosen design meets its own requirements and that the assessor agrees with the evidence.

What should a quote for SC.L2-3.13.15 cover?

A quote should follow from a written scope that names the systems, session types and components in play. Ask the provider to state what it will configure, what it will document and what evidence it will hand over, such as configuration exports, certificate records and log samples. Ask whether the price is one-time or recurring, and what happens when certificates are renewed or new systems join. DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. Ongoing support is available as a retainer. DeployOpen prepares systems and evidence, but it does not issue assessment reports or certificates. Those come from an independent assessor.

How DeployOpen scopes and prepares session authenticity evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, under a fixed-scope written agreement that sets the systems, deliverables and timelines before work starts. For SC.L2-3.13.15, the first scoping decision is which communications sessions the organization must protect. That list usually covers device-to-device traffic between servers, certificate-based service connections, administrative sessions and any session carrying CUI. Each session type needs a named protocol, a named identity source and a named owner, and the written scope should list them so the assessor can trace the requirement to specific systems. DeployOpen's preparation work covers the configuration and records that show session authenticity is in place. Typically this includes the certificate authority and its issuance workflow, the mutual authentication settings for each service, the trust chains that clients and servers validate, and the audit records that show who was issued or revoked credentials. Open-source components such as FreeIPA, which includes an integrated certificate authority, and OpenBao, whose PKI secrets engine issues short-lived X.509 certificates, can produce this evidence when they are configured for the client's environment. Confirm the exact certificate lifetimes, enrollment methods and supported protocol versions against each product's documentation and the client's own policy, not against this page. DeployOpen does not issue audit reports, attestations or certifications. The organization owns its controls and its system security plan, and an independent assessor, such as a C3PAO for Level 2 certification assessments, decides whether the requirement is MET. DeployOpen can provide ongoing support and upgrades as a retainer, which suits organizations that need certificate rotation, protocol updates and evidence refreshes between assessments. Any retainer scope, like the initial engagement, is priced from the written scope, so ask for a quote that lists each system, each evidence item and who is responsible for maintaining it.

SC.L2-3.13.15 Communications authenticity