SC-23: Session Authenticity

To meet the sc-23: session authenticity requirement, you must ensure every communications session your systems establish is protected against impersonation and session takeover by using authenticated session setup and strong cryptographic protections for session establishment and resumption ¹. Operationalize SC-23 by defining where “sessions” exist, standardizing approved protocols/configurations, and producing repeatable evidence that protections are deployed and monitored.

Key takeaways:

• Scope “sessions” across apps, APIs, admin access, and service-to-service traffic, then prioritize high-risk paths.
• Enforce authenticated session establishment (certificate validation, signed tokens, mutual authentication where appropriate) and block downgrade/weak configurations.
• Keep auditable artifacts: standards, configs, test results, and logs that prove sessions are authentic and controls operate.

SC-23 is a deceptively short requirement: “Protect the authenticity of communications sessions” ¹. For a CCO or GRC lead, the operational translation is concrete: prevent attackers from successfully posing as a legitimate endpoint or hijacking an established session between two endpoints (user-to-app, app-to-API, service-to-service, administrator-to-console, and third-party connections). If your environment uses web apps, APIs, SaaS admin consoles, remote access, message queues, or east-west microservice traffic, you have “sessions” that can be spoofed, replayed, downgraded, or intercepted.

Auditors rarely accept “we use TLS” as a complete answer. They will ask where TLS is terminated, whether certificate validation is enforced, how you handle session resumption, what controls exist for internal traffic, and what evidence proves the standard is consistently applied. Your fastest path is to (1) define session types and trust boundaries, (2) set a baseline for approved protocols and authentication methods, (3) implement configuration guardrails and monitoring, and (4) retain evidence that is easy to re-perform and re-check.

This page gives requirement-level implementation guidance you can hand to control owners and then assess quickly.

Regulatory text

Control requirement (verbatim excerpt): “Protect the authenticity of communications sessions.” ¹

What an operator must do: Implement technical and procedural controls so that endpoints participating in a session can verify they are talking to the intended counterparty, and so session establishment/resumption can’t be forged, altered, replayed, or downgraded without detection ¹. In practice, this means you set and enforce standards for authenticated session setup (commonly via TLS with strict certificate validation, and signed/validated tokens for application sessions) and you produce evidence that these standards are deployed across in-scope systems.

Plain-English interpretation (what SC-23 is really asking)

SC-23 expects you to stop three common failure modes:

1. Endpoint impersonation: A user or system connects to a fake server, or a fake client connects to a real server, because identity wasn’t verified (for example, weak certificate validation).
2. Session hijacking: An attacker steals or predicts session material (cookies, bearer tokens, session IDs) and takes over an existing session.
3. Session manipulation: An attacker forces a weaker protocol/cipher, replays a session setup, or tampers with session negotiation.

A good SC-23 program answers: “How do we prove the session is genuine at establishment, and how do we protect session continuity and resumption?”

Who it applies to (entity and operational context)

SC-23 commonly applies to:

• Federal information systems and contractor systems handling federal data aligned to NIST SP 800-53 ².
• Any organization using NIST SP 800-53 as a control baseline for regulated environments, customer security requirements, or contractual obligations.

Operational contexts where auditors will scope SC-23 quickly:

• External web apps and APIs (public internet exposure).
• Administrative access paths (SSO to admin consoles, bastions, VPN/Zero Trust gateways).
• Service-to-service traffic inside your network or cloud (microservices, Kubernetes, messaging).
• Third-party connections (B2B APIs, SFTP, private links, managed service providers).

What you actually need to do (step-by-step)

Use this as an execution checklist that produces audit-ready artifacts.

Step 1: Define “session” and inventory where sessions exist

Build a simple Session Inventory table with:

• System/app name, environment (prod/non-prod)
• Session type (browser, API, SSH, mTLS service mesh, DB connection, message broker)
• Trust boundary (internet-facing, partner network, internal)
• Termination points (load balancer, API gateway, service mesh sidecar)
• Authentication method (TLS server auth, mTLS, token-based, SSH keys)
• Owners (app owner + platform owner)

Focus first on session paths that cross trust boundaries.

Step 2: Set a baseline standard for session authenticity

Publish a Session Authenticity Standard that states:

• Approved session protocols (for example, TLS for HTTP-based sessions; SSH for admin; mTLS where appropriate for service-to-service).
• Requirements for certificate validation (no disabling verification, defined trust stores, rotation expectations).
• Session token rules (signed tokens, audience/issuer validation, expiration, replay resistance where applicable).
• Controls for downgrade prevention (disable legacy protocol versions and weak negotiation modes).
• Minimum logging required to support detection/forensics.

Keep this standard tight and testable. Your goal is to make configuration drift obvious.

Step 3: Implement technical controls per session type

Map the standard to concrete platform controls:

A. Browser and API sessions (HTTP/S)

• Enforce HTTPS and redirect/block plaintext.
• Enforce strict server certificate validation at clients and gateways.
• Use authenticated session mechanisms:
  • For browser sessions: secure cookies, HttpOnly, SameSite where appropriate, session ID rotation after privilege changes.
  • For APIs: signed tokens with issuer/audience validation; short-lived access where feasible; bind tokens to TLS channel or client where your architecture supports it.
• Protect session establishment and resumption: configure TLS properly at the edge and at internal hops where needed.

B. Service-to-service sessions

• Prefer mTLS for east-west traffic where services are separately managed or multi-tenant.
• Centralize identity with a service mesh or mutual-auth capable gateway when practical.
• Verify service identity, not just network location (IP-based trust fails under lateral movement).

C. Admin sessions

• Use strong, authenticated remote administration protocols.
• Require MFA at the identity layer for interactive admin where possible.
• Prevent administrative sessions from bypassing inspection and logging.

Step 4: Add guardrails to prevent drift

• Infrastructure-as-code baselines for TLS and gateway configs.
• CI/CD checks (linting for insecure session settings, blocked merges for known-bad configs).
• Central policy where available (gateway policies, service mesh policies, endpoint management baselines).

Step 5: Monitor and test session authenticity continuously

You need detection and verification:

• Scan for services allowing plaintext or weak protocol negotiation.
• Monitor for certificate errors, unusual session patterns, and token validation failures.
• Add periodic validation: configuration reviews plus technical testing (automated where possible).

Step 6: Assign ownership and make evidence recurring

SC-23 fails most often because nobody owns it end-to-end. Assign:

• Control owner: security architecture / security engineering (design authority)
• Operators: platform, network, SRE, IAM, app teams (implementation)
• GRC: ensures evidence exists and matches the standard

Daydream fits naturally here as the system of record to map SC-23 to owners, implementation procedures, and a recurring evidence checklist so you can answer audits without rebuilding the narrative each cycle ¹.

Required evidence and artifacts to retain

Auditors look for proof of design and operation. Maintain these artifacts in a single control binder:

1. Session Inventory (system list + session types + boundaries + owners).
2. Session Authenticity Standard (approved protocols, validation rules, exceptions process).
3. Architecture diagrams showing termination points and trust boundaries.
4. Configuration evidence (sanitized):
   • Load balancer / API gateway TLS policy exports
   • Service mesh mTLS policy/config
   • Client configuration snippets showing certificate validation enabled
5. Testing evidence:
   • Results of scans for plaintext endpoints and weak protocol support
   • Sample validation tests (e.g., failed handshake on weak protocols)
6. Monitoring evidence:
   • Log samples showing TLS/session-related events
   • Alerts/runbooks for session anomaly response
7. Exception register with compensating controls and expiry dates.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where sessions are established and terminated for this customer-facing app.”
• “How do you ensure clients validate certificates? Do you ever disable validation?”
• “Do internal services authenticate each other, or do you trust the network?”
• “How do you prevent protocol downgrade or legacy protocol usage?”
• “What’s your exception process for legacy systems?”

Hangups that stall audits:

• No authoritative inventory of session types.
• TLS is enabled at the edge, but internal hops are plaintext without a documented risk decision.
• Token validation is inconsistent across microservices.
• Evidence is screenshots-only with no repeatable exports or automated tests.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SC-23 as “TLS on the website.”
   Avoidance: scope sessions for APIs, admin paths, service-to-service, and third-party connections.

2. Mistake: Allowing certificate validation bypass in clients.
   Avoidance: block insecure options in shared libraries, add CI checks, and require exception approval with expiry.

3. Mistake: Token-based sessions without strong validation rules.
   Avoidance: standardize issuer/audience checks, signature verification, and key rotation ownership.

4. Mistake: No story for session resumption.
   Avoidance: document how resumption works in your stack (edge, gateway, service mesh) and ensure it inherits the same authenticity guarantees.

5. Mistake: Evidence scattered across teams.
   Avoidance: a control binder with recurring evidence owners and due dates; Daydream can track this mapping so audits don’t become a scavenger hunt ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, SC-23 gaps raise breach likelihood through session hijacking and impersonation paths, and they complicate incident response because you can’t prove which endpoint was actually on the other side of a sensitive session ².

Practical 30/60/90-day execution plan

The rules for this plan are simple: make scope explicit, implement guardrails, then make evidence repeatable.

Day 30: Scope and standardize

• Complete a first-pass Session Inventory for high-impact systems.
• Publish a Session Authenticity Standard with clear “must” statements and an exception process.
• Identify your top session termination points (gateways, load balancers, identity proxies) and name owners.

Day 60: Implement guardrails on priority paths

• Enforce approved session configurations on internet-facing apps and APIs first.
• Implement service-to-service authentication where trust boundaries are weakest (multi-account, multi-cluster, partner connectivity).
• Add CI/CD checks or configuration policies to prevent known-bad session settings.

Day 90: Prove operation and close evidence gaps

• Run and archive repeatable tests (scans, config exports) that demonstrate compliance with the standard.
• Add monitoring/alerting for certificate errors, token validation failures, and unexpected plaintext endpoints.
• Formalize the control binder in Daydream: owner mapping, procedures, evidence checklist, and recurring collection.

Frequently Asked Questions

What counts as a “communications session” for SC-23?

Any sustained exchange where endpoints maintain state or negotiate security parameters, including browser sessions, API calls with bearer tokens, SSH sessions, VPN/ZTNA sessions, and service-to-service connections ².

If we already use HTTPS everywhere, are we done?

Usually not. Auditors will test whether certificate validation is enforced, whether internal hops preserve authenticity guarantees, and whether token/session handling prevents hijacking and replay ¹.

Do we need mTLS for internal microservices to satisfy SC-23?

SC-23 requires session authenticity, not a single prescribed technology. mTLS is a common way to prove both sides of a service-to-service session are authentic, especially across meaningful trust boundaries ².

How do we handle legacy systems that can’t meet the standard?

Use a time-bound exception with compensating controls such as isolation, gateway termination, strict allowlisting, and enhanced monitoring, and keep the exception in your control binder with an expiry date ¹.

What evidence is most persuasive in an assessment?

A written standard, a scoped inventory, exported configurations from gateways/meshes, and repeatable test results showing weak sessions are blocked. Screenshot-only evidence tends to slow assessments because it’s hard to reproduce ¹.

Where does Daydream help with SC-23?

Daydream is useful as the operational system of record: mapping SC-23 to the control owner, implementation procedure, and recurring evidence artifacts so you can answer audits consistently without re-creating documentation each cycle ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5