SC-23 Session authenticity: requirements and evidence

What SC-23 session authenticity asks for and why sessions get hijacked

SC-23 asks the organization to protect the authenticity of communications sessions, so that an attacker cannot take over an established session, replay captured session traffic or sit in the middle of a conversation between a user and a system. A compliance lead usually meets this control in one of two ways: an assessor testing a moderate or high impact system, or a FedRAMP authorization at Class C or D, where the control is required. SC-23 is a base control with no organization-defined parameters, so the assessor will not ask you to fill in a value. The question is whether your design protects sessions in practice and whether you can show how.

The control is hard to satisfy because a session is not a single component. A user session may pass through a browser, a content delivery layer, a load balancer, an API gateway, an application server and an identity provider, and each hop can hold or refresh a session identifier. Authenticity protection is therefore spread across several layers that different teams own: network engineers own TLS termination, application teams own cookie and token handling, and platform or identity teams own logout and token lifetimes. Before you plan any evidence, map which layer issues, stores, validates and destroys each session identifier, because a gap in one layer is invisible from the others.

In SP 800-53B, SC-23 sits in the moderate and high baselines, but none of its five enhancements is assigned to any baseline. That means your organization must decide, and document, whether to adopt enhancements such as invalidating session identifiers at logout or using unique session identifiers. Confirm the enhancement wording in the SP 800-53 Rev. 5 catalog before you write it into your system security plan, and record a reasoned decision for each one you decline. An assessor will accept a justified exception more readily than a silent omission.

Which systems, sessions and teams fall inside SC-23 scope

SC-23 applies to the system as a whole, so scope is set by which sessions the system issues, accepts or carries, not by which team owns an application. Each card below names a session type, the team that usually decides it, and what changes the work. Confirm each decision in the system security plan before assessment starts.

User-facing web applications

Browser sessions that carry a user's authenticated state are the core of SC-23. Assessors look at how session identifiers are created, how they travel (cookies with secure attributes, tokens in headers) and whether they are regenerated after sign-in. The application team owns the session code, but the platform team often owns cookie settings at the proxy. Confirm which team sets each attribute and where that setting is recorded.

Administrative consoles

Management interfaces usually carry higher-privilege sessions and are often reached through a separate hostname, host or access path. Their session lifetime, re-authentication rules and logout behavior may differ from the user application. Infrastructure or security operations teams usually own these consoles, so they need their own entry in the scope statement, not a footnote under the main application.

APIs and service sessions

Machine-to-machine calls use bearer tokens, client credentials or mutually authenticated channels rather than browser cookies. SC-23 asks whether these sessions can be hijacked or replayed, so token lifetimes, audience checks and certificate-bound credentials belong in scope. Platform or integration teams usually own them. Ask whether service tokens are inventoried, because unlisted service sessions are a common assessment gap.

Identity providers and single sign-on

Deciding whether the organization runs its own identity provider changes the work substantially. Self-hosted options such as authentik, which acts as an identity provider for applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, put session issuance inside the boundary. When applications delegate sign-in to a central provider, the provider's session controls become a shared dependency that must be documented and tested. Identity and access teams usually own this decision.

Reverse proxies and load balancers

Components that terminate TLS or set session cookies can alter session behavior even when the application is correct. Check whether the proxy rewrites cookie flags, handles session stickiness or strips authentication headers. Network or platform engineering usually owns these components, so changes to them should trigger a review of the SC-23 evidence, not just the network change record.

Third-party hosted services and inherited controls

Hosted services that issue or carry sessions, and cloud or hosting provider controls, sit outside the organization's direct configuration. Document them as inherited only where the provider's own assessment evidence covers the specific session behavior. Procurement and the system owner usually decide this boundary. Anything not covered by inherited evidence stays the organization's responsibility and needs its own test evidence.

How an assessor tests SC-23 and what they ask to see

This table maps the SP 800-53A assessment methods for SC-23 to the objects an assessor examines, the people they interview, the tests they run and the findings they commonly raise. Read it as a preparation list: each row shows what to have ready before the assessor arrives. The assessor decides the outcome, so confirm the current procedure wording in the SP 800-53A OSCAL content before relying on any row.

Assessment element	What the assessor does	Evidence to have ready	Common findings
Examine: system design documentation	Reads how the system creates, binds, renews and ends session identifiers, and where session state is kept.	Architecture diagrams, authentication and session design notes, and a description of which components issue and validate session identifiers.	Design documents omit the session mechanism or describe a mechanism the running system does not use.
Examine: system configuration settings and documentation	Checks session timeout, identifier lifetime, cookie attributes and token settings against the documented design.	Exported configuration for web servers, reverse proxies and identity providers, with change records showing who set each value and when.	Settings differ between environments, or documented lifetimes are longer than the configured values.
Examine: system audit records	Looks for logged session creation, logout, expiry and rejected session events that show the mechanism operating.	Sample logs covering logins, logouts and failed session validations, with time synchronized across sources.	Logout and expiry events are not logged, so the assessor cannot confirm that sessions end as designed.
Interview: application owners	Asks how the application issues, rotates and invalidates session identifiers and how it handles logout across tabs and devices.	Named owners, a short walkthrough of the session lifecycle and the test accounts used for demonstrations.	Owners describe session handling from memory and disagree with the design document.
Interview: platform and identity owners	Asks how the identity provider and proxies create sessions, pass identity assertions and terminate sessions centrally.	Written responsibilities for each platform component and the procedure for revoking sessions.	Responsibility for session termination is split between teams with no single owner.
Test: session behavior after logout	Logs out, then replays the old session identifier against protected resources to confirm it is rejected.	Repeatable test scripts, captured request and response pairs, and results with dates and tester names.	The old identifier still grants access after logout, or it is accepted briefly on cached responses.
Test: replayed or altered identifiers	Submits copied, modified or expired identifiers and checks whether the system rejects them and logs the attempt.	Test cases for tampered, expired and reused tokens, with the system's responses and log entries.	Identifiers can be altered without detection, or the system accepts a token whose signature is not validated.
Test: predictability and sharing	Samples many identifiers to check randomness and confirms each session gets a unique value.	Documentation of the random source used, and results from sampling identifiers across users and instances.	Identifiers are predictable, reused across users, or shared between load-balanced nodes with the same secret.
Test: protected connections	Confirms session identifiers travel only over protected connections and cannot be exposed in URLs or logs.	Protocol settings, cookie flags and sample traffic captures showing encrypted transport for session data.	Session identifiers appear in URLs, plain HTTP redirects or application logs.

How to implement SC-23 in six steps

This sequence takes a team from an unknown set of sessions to a documented, tested and examinable design for session authenticity under SC-23. Each step ends with an artifact an assessor can read, so the work produces evidence as it goes rather than at the end.

Inventory every session type and issuer
Start by listing each place the system creates a session: user logins to web applications, administrative consoles, API tokens, service-to-service connections, and remote access paths. For each one, record which component issues the session identifier, where it is stored, how long it lives, and which team owns it. Shared identity services and reverse proxies belong on the list because they often issue sessions on behalf of applications. The output is a session inventory that the team reviews with the application owners. The step is done when every application in scope appears with a named issuer and a named owner.
Decide mechanisms and transport protections per session
For each inventoried session, decide how its authenticity is protected. Typical choices include TLS for every channel that carries session identifiers, signed or server-side session tokens, binding of sessions to the authenticated user, and protection of cookies against theft and reuse. Record the reasoning next to each entry, including where a session crosses a boundary you do not control. The architect and the security lead sign off on the decisions. The output is a design note that maps each session type to its mechanism and transport protection, and the step is done when no session in the inventory lacks a decision.
Decide on logout invalidation and unique identifiers
Review the optional SC-23 enhancements against the session inventory and decide which to adopt. The enhancements cover invalidating session identifiers at logout and generating unique session identifiers that are recognized only by the system that issued them. Note which applications can invalidate sessions server side, which rely only on clearing a browser cookie, and what that means for the risk they accept. Record each adopted or declined enhancement with its rationale and the owner who accepts the decision. The output is the enhancement decision record, which the assessor will compare against the design note. The step is done when each enhancement has a recorded decision.
Configure identity providers and applications
Engineers configure the identity provider and each application so the decisions from the earlier steps are enforced in the running system. For example, applications that delegate sign-in to a self-hosted identity provider such as authentik need their provider settings and token lifetimes exported, and applications that rely on Kerberos single sign-on through FreeIPA need their ticket and service configuration recorded. Certificates used for TLS should come from a managed issuer so that renewal is automated. The output is a set of configuration exports and a short change log, stored under version control. The step is done when a reviewer can trace each session type in the inventory to a concrete setting.
Test session behavior including replay and logout
Test each session type against the designed behavior. Cases should include reuse of a captured session identifier from another client, replay of a previously valid token, a session that continues after logout, a session that continues after the user changes credentials, and whether tampering with a session token is detected. Run tests in a non-production environment that matches the production configuration, and retain the requests, responses and results. Findings go into the plan of action and milestones with an owner. The output is a test record for each case, and the step is done when every designed behavior has a passing result or an open, tracked finding.
Record design and configuration for examination
Assemble the artifacts so an assessor can examine them without a walkthrough. The package should include the session inventory, the design note, the enhancement decisions, the configuration exports, the test records and the audit records that show session creation, use and termination. Confirm that audit logs capture session events with reliable time stamps, because assessors use them to check that the design operates. The organization owns this package and the control itself, and an independent assessor reviews it. The output is a versioned evidence folder linked from the system security plan, and the step is done when a reviewer who did not build the system can follow each session from design to test result.

Evidence that satisfies SC-23 and how to keep it current

An assessor testing SC-23 Session authenticity looks for a design that explains how sessions are built and protected, configuration that matches that design, and records that show it working. The cards below cover the artifacts that connect those three, with a refresh rhythm and trigger for each so the evidence stays accurate as applications and providers change.

System design document for sessions

The design document describes how sessions are established, how session identifiers are generated and protected, where session state lives, and how TLS protects the channel carrying them. Assessors examine this document first, so it should name each application, identity provider and proxy that issues or validates a session. Check that it states how identifiers are made unique and how they are invalidated at logout. Refresh it whenever session establishment changes, such as a new application, a new identity provider or a changed token lifetime.

Identity provider and application configuration exports

Export the settings that control sessions from each identity provider and application, such as token lifetimes, logout behavior, cookie flags and the protocols enabled. Providers such as authentik delegate sign-in to applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each application's configuration must match the provider it uses. Store exports under version control so an assessor can compare current settings with the approved design. Refresh the exports after every provider upgrade or change to a provider binding.

Logout and session-expiry test results

Record tests that prove a session identifier stops working after logout and after the configured expiry period. Test from a clean browser, replay a captured identifier, and confirm the server rejects it. Keep the test script, the date, the tester and the result for each application. These results show the invalidation enhancement is operating, not only designed. Repeat the tests after any change to logout handling, a new application or an upgrade to the component that manages sessions.

Audit records of session activity

Collect audit records showing session creation, session invalidation and failed authenticity checks, such as rejected or tampered identifiers. Confirm each record includes a reliable timestamp and the account or service involved, and that the clocks feeding the logs are synchronized. Assessors use these records to see whether the design runs in practice. Review a sample each month to confirm events are arriving. Re-verify log fields whenever logging is reconfigured or a new application starts sending events.

Session inventory

Maintain a list of every application and service that creates or accepts sessions, with its owner, identity provider, session lifetime, TLS endpoint and whether it supports unique identifiers and logout invalidation. The inventory shows assessors that no session path sits outside the design. Gaps usually appear where legacy applications keep local session stores. Update the inventory when an application is added, retired or moved, and reconcile it against the identity provider's list of connected applications at each review.

Change record linking to the SSP

Keep a change record that ties each session design change to the SC-23 entry in the system security plan, with the reason, the approver, the date and the tests run afterward. This record proves the plan describes the system as it currently runs. Without it, an assessor cannot tell whether a configuration change was reviewed against the control. Update the SC-23 entry and this record with every approved change, including provider upgrades and changed TLS configurations, and confirm the SSP text still matches the design document.

What meeting SC-23 costs in money and effort

This table compares the cost components of meeting SC-23 Session authenticity, showing who is paid, whether each cost is one-time or recurring, what drives it up or down, and how self-hosted open-source identity components can reduce license spend. No public prices exist for these components, so use the table to shape what you request in a written quote.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Identity and session tooling or licenses	Recurring (subscriptions) or one-time (perpetual licenses), depending on vendor	Number of applications and identity providers in scope, user counts, and whether you already run an identity provider that covers the session paths	Confirm which session paths your existing identity provider already governs before buying. Self-hosted open-source options such as authentik (MIT) and FreeIPA (GPL-3.0-or-later) can remove license spend, though support and hardening still carry cost
Engineering time to design session handling	One-time for the design, with periodic revision	Whether applications delegate sign-in to a central identity provider or implement sessions themselves, and how many distinct session types exist	Delegate sign-in to one identity provider over OAuth2, OpenID Connect or SAML where possible, so session logic is configured once rather than rebuilt per application
Configuration of session identifiers, logout and timeouts	One-time per application, plus changes after upgrades	Count of custom-built session mechanisms, and whether session identifiers are generated and invalidated by the framework or by hand	Use framework defaults that already issue unique identifiers and invalidate them at logout, and document any deviation so reviewers do not need to reverse-engineer it
Testing effort for hijacking, replay and man-in-the-middle cases	Recurring, at each release and after significant changes	Number of applications with custom sessions, presence of cookies or tokens shared across services, and the depth of test scripts retained	Build repeatable test cases for session fixation, reuse after logout and token replay once, then run them in the existing pipeline
External penetration or session testing	Recurring, usually annual or per major change, per the organization's own policy	Scope of applications and APIs, complexity of authentication flows, and whether testing covers federation and token exchange	Define the test scope in writing before engagement, and limit it to session-relevant surfaces where the risk assessment supports that choice
Evidence upkeep (configuration exports, logs, design records)	Recurring, with each assessment cycle	Number of identity providers and applications that must show session settings, and whether logs of session events are centralized	Export configuration automatically and retain audit records of session events in one place. Confirm retention periods with your assessor
Auditor sampling and assessment effort	Recurring, per assessment cycle, set by the independent assessor	Number of applications sampled, quality of existing evidence, and how many exceptions the assessor raises	Ask the assessor to state the sample basis in the engagement letter, and prepare consistent evidence for each sampled application before fieldwork begins
Time synchronization and log correlation support	One-time setup, recurring monitoring	Number of hosts and services that record session events, and whether time sources are consistent across them	Confirm that session-related logs share a single time source so they can be correlated during an assessment

Which self-hosted open-source tools support SC-23 evidence

SC-23 is about whether sessions stay authentic from sign-in through logout, and most of that depends on the application. The tools below cover the surrounding pieces: who signs users in, how services get trusted certificates, and where that activity gets recorded. Each one produces some evidence an assessor can examine, but none of them proves on its own that a session is protected.

authentik sign-in delegation

authentik is an identity provider that applications can delegate sign-in to through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Centralizing sign-in means the session lifetime, logout endpoint and token settings are defined once and can be exported as configuration for an assessor to examine. Confirm that each connected application actually calls the logout endpoint and discards its own session identifier, because a central provider cannot end a session the application keeps alive. Check the logout and identifier behavior in the version you run, not only in the documentation.

FreeIPA Kerberos single sign-on

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos key distribution center. Kerberos tickets have their own lifetimes and renewal rules, so ticket policy settings and KDC logs can show how long authenticated sessions last on hosts enrolled in the realm. What FreeIPA does not do is control the session behavior of web applications or services that never use Kerberos. Ask which systems in your environment rely on the realm and which still use separate, application-managed sessions.

OpenBao certificate issuance records

The OpenBao PKI secrets engine issues dynamic X.509 certificates, so services receive short-lived certificates without generating a key and certificate signing request by hand and waiting for a CA to sign it. Issuance logs and role definitions show which identities received certificates, when, and for what names, which supports the authenticity of the endpoints that sessions run over. Certificate issuance does not secure a session by itself. Confirm that clients validate the certificate chain and that the lifetimes configured in your roles match your session design.

cert-manager Kubernetes TLS renewal

cert-manager creates TLS certificates for workloads in Kubernetes or OpenShift from issuers such as ACME, a CA key pair, HashiCorp Vault, CyberArk or a self-signed issuer. It stores each certificate in a Kubernetes Secret and renews it before expiry, and its resource status and events record issuance and renewal for an assessor to review. Renewal keeps the endpoint certificate current but does not confirm that the application terminates TLS correctly or invalidates sessions at logout. Ask which issuer each namespace uses and whether self-signed issuers are limited to non-production clusters.

Who owns SC-23: your team, an implementation partner and the auditor

Your organization owns SC-23. That means accountability for deciding how sessions are protected, recording the decisions in the system security and privacy plan, and accepting the residual risk when a session behavior is weaker than the ideal. The control is about protecting sessions against hijacking, replay and man-in-the-middle attacks, so the design choices sit with people who understand the application's trust boundaries, its users and its data.

Session design decisions: Set session lifetimes, idle timeouts, token binding approach, how session identifiers are generated and rotated, and what happens at logout.
System security plan entry: Write the SC-23 implementation statement so it names the systems, the mechanisms and the responsible role for each.
Configuration ownership: Keep the identity provider and application session settings under change control so the documented values match what runs.
Evidence custody: Retain configuration exports, audit records and test results where the assessor can request them.
Sign-off: Approve the design and any exceptions through the risk acceptance process, and track deviations in the plan of action and milestones.

Check that someone on your side can explain every session setting in the plan without referring to the vendor or partner.

Where SC-23 programs usually fall short and how to close each gap

Session authenticity programs tend to fail in the same places: logout handling, inconsistent session design across applications, undocumented reliance on transport protection, untracked identity provider changes, untested replay and logout behavior, and legacy applications nobody inventoried. Each card names one gap and the action and evidence that close it.

Session identifiers not invalidated at logout

Applications often clear the browser cookie at logout but leave the server-side session valid, so a copied identifier still works after the user has left. An assessor testing SC-23 will look for server-side invalidation and will replay a captured identifier after logout to confirm it is rejected. Close the gap by making logout destroy the session on the server, then keep the test result and the configuration that enforces it as evidence. Check identity provider logout endpoints too, not only the application.

Session design varies by application

Each team sets session lifetimes, identifier generation and cookie attributes on its own, so the organization has no single answer to how sessions are protected. Without one design record, an assessor cannot confirm that the system meets the requirement for every session path. Write one session design standard covering identifier entropy, uniqueness, cookie flags and lifetimes, and require each application to reference it in its system documentation. The design record is the document the assessor examines first.

Transport protection assumed, not documented

Teams often assume that because the site uses HTTPS, session authenticity is covered, but the protection depends on how TLS is terminated, which proxies sit in front of the application and whether internal hops are encrypted. If that chain is not written down, the reliance on inherited protection cannot be verified. Map every hop that carries session tokens, record where TLS is terminated, and tie each hop to the transmission controls that protect it. Ask the assessor's team which evidence they expect for inherited protection before the test.

Identity provider changes without evidence

Session behavior is set in the identity provider as well as in applications, so changes to token lifetimes, signing settings or logout configuration alter authenticity without touching application code. When those changes happen without a record, the organization cannot show what the session rules were at any given date. Put identity provider configuration under version control, require review for changes, and retain exported configuration with change approvals. Compare exports over time to show the rules that were actually in force.

No replay or logout testing

Many programs review session settings but never try to hijack or replay a session, so weaknesses surface only in an external test or an incident. An assessor expects evidence that session handling was tested, not only described. Build test cases for replay of an identifier after logout, reuse across sessions, and fixation at login, then run them against each application and record the results. Retest after every change to authentication or session code. The test scripts and dated results are the evidence.

Legacy and third-party sessions not inventoried

Older internal tools, vendor appliances and purchased applications often manage their own sessions and sit outside the main authentication design, so they are missed in scope. An assessor who finds an application with no documented session handling will record a finding against the whole program. Inventory every system that issues or accepts sessions, including vendor products, and record how each handles identifiers, logout and timeouts. Where a system cannot meet the design standard, document the compensating control and the plan to replace or isolate it.

SC-23 questions buyers ask before hiring outside help

How much effort does SC-23 take compared with other SC controls?

SC-23 is usually a narrower engineering task than boundary protection or cryptographic key management, because it concentrates on how sessions are created, bound and ended rather than on network architecture or key lifecycles. Its single determination statement in SP 800-53A Release 5.2.0 is short, but the work still touches every application that issues session identifiers. Effort rises with the number of applications, the mix of identity providers and whether sessions cross trust boundaries. SC-7, SC-8 and SC-12 typically involve more systems and more evidence, so SC-23 is often smaller in scope but not trivial. Ask a partner to count the applications and session types in your environment before comparing effort across controls, since that count, not the control number, drives most of the difference.

Can we implement SC-23 without an outside partner?

Yes, an organization can implement SC-23 with its own engineers, and many do. The control is owned by the organization, and nothing in SP 800-53 requires an external firm to build it. The practical question is whether your team has the time and the skills to configure session handling across applications, identity providers and proxies, then to collect evidence an assessor will accept. Outside help is most useful when the environment is heterogeneous, when several teams own different applications, or when the deadline is tied to a contract or authorization. A partner prepares systems and evidence; only an independent assessor or auditor can test the control and issue findings or reports. Plan for that separation from the start.

What does SC-23 need from our engineers and identity owners?

SC-23 needs both application engineers and identity owners, because session behavior is set in code and in identity configuration. Application teams must confirm how session identifiers are generated, stored, rotated and invalidated at logout. Identity owners must confirm which provider issues sign-in, how sessions are bound to the authenticated user and how the provider is configured for OAuth2, OpenID Connect, SAML or proxy flows. Security engineers should review the design documentation and the audit records that show session events. Expect to provide access to configuration, test accounts and logs, and to name a decision owner for exceptions. Where a single identity provider such as authentik serves many applications, one owner can cover most of the configuration, but each application still needs its own check.

How long does SC-23 work take, and what changes the timeline?

The timeline depends on the scope agreed in writing, and no duration for SC-23 is set by NIST. The main drivers are the number of applications and session types, the state of existing identity configuration, the amount of custom session code, and how quickly your teams can review and approve changes. Work that involves a single identity provider with well-documented applications usually moves faster than work that spans legacy applications with bespoke session handling. Assessor scheduling and the evidence cycle also add time. Ask for milestones tied to specific applications and for a clear list of dependencies on your teams, such as change windows and test environments. A fixed-scope engagement sets these items out before work starts.

Is SC-23 alone enough for FedRAMP or a contract?

No. SC-23 is one control among many in the SP 800-53 catalog, and FedRAMP and contracts assess a system against a full baseline. FedRAMP's Rev5 baselines require SC-23 at Classes C and D, but the same authorization also depends on identification and authentication, access control, audit, encryption and documentation controls. The FedRAMP 20x indicators list SC-23 among related controls for several key security indicators, which shows how it connects to identity and least privilege work rather than standing alone. Confirm with the contracting authority which baseline and class apply, and which controls its assessors will test. Treat SC-23 as one required input to a broader system security plan and assessment, not as a self-contained compliance result.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that names each application and identity provider in the session boundary, the session behaviors to be configured, and the evidence to be produced for each. Request the deliverables list, the responsibilities split between your team and the partner, and the assumptions the quote depends on, such as access, test environments and change windows. Ask which costs are one-time and which recur, for example support, upgrades or continuous testing under a retainer. Confirm that the partner prepares evidence but does not issue any audit report or attestation, and ask who engages the independent assessor. NIST does not estimate compliance or certification costs, so the figure must come from the partner's written scope, not from a published rate. DeployOpen does not publish a price list; a quote follows from the agreed scope.

How DeployOpen scopes, implements and prepares SC-23 evidence

DeployOpen works on SC-23 Session authenticity by scoping the session paths in your environment, implementing self-hosted open-source controls that protect them, and preparing the configuration and records an independent assessor will examine. The organization keeps ownership of its control decisions, and only an independent assessor issues an assessment result.

How we scope

Inventory the applications and interfaces that create user sessions and list where session identifiers are issued and stored.
Agree in writing which session types, identity paths and systems fall inside the SC-23 scope before work begins.
Confirm with your assessor which SP 800-53B baseline and tailoring decisions apply to the system in scope.

How we build

Configure identity providers such as authentik or FreeIPA so applications delegate sign-in rather than managing their own sessions.
Set session lifetimes, logout behavior and identifier handling in the application configuration, then test them against the scoped design.
Where TLS protects session traffic, issue and renew certificates through OpenBao or cert-manager so session endpoints stay protected.

How we hand over

Deliver the session design documentation and configuration settings that an assessor would examine for SC-23.
Provide test records showing logout invalidation, session identifier uniqueness and replay resistance as they were tested in your environment.
Hand over audit record samples and a runbook so your team can rerun the checks and keep the evidence current.

How we support

Support is available as a retainer for upgrades, configuration drift checks and re-testing after significant changes.
Re-run session tests after identity provider, application or certificate changes, and update the documentation to match.
DeployOpen prepares evidence for your assessment but does not issue audit reports, attestations or certifications.