AU-14(1): System Start-up

AU-14(1): System Start-up requires you to start session auditing automatically whenever a system starts, without relying on an admin to “turn logging on.” You operationalize it by baking audit/session capture into boot-time services, validating it survives restarts and failover, and retaining evidence that proves audits begin at start-up across all in-scope hosts. ¹

Key takeaways:

• Make session audit initiation a boot-time, enforced configuration, not a manual runbook step. ¹
• Prove it works after restarts, patch cycles, autoscaling, and DR events, because auditors will test those edges. ¹
• Retain technical evidence (configs, startup logs, test results) tied to a named control owner and a recurring check cadence. ¹

AU-14(1): system start-up requirement sits in the audit family and is easy to misunderstand because the text is short. “Initiate session audits automatically at system start-up” is a design requirement more than a policy statement. It forces you to treat session auditing as a default security property of the system, not an operational preference.

For a CCO or GRC lead, the fastest path is to translate AU-14(1) into two questions you can validate: (1) “What counts as a session audit for our systems?” and (2) “What mechanism guarantees it begins at boot every time?” Then you operationalize it by tying each mechanism to an owner, hardening it against common failure modes (service disabled, agent not installed, boot race conditions, image drift), and building clean evidence that an assessor can replay.

This page gives requirement-level guidance you can assign to engineering: a concrete implementation pattern, a minimal test plan, and the evidence set to retain so you can pass an assessment without scrambling. The goal is not more logs. The goal is reliable session auditing from first boot forward. ²

Regulatory text

Requirement (verbatim): “Initiate session audits automatically at system start-up.” ¹

Operator meaning: If a system is rebooted, redeployed from an image, scaled out, failed over, or recovered from backup, session auditing must start without human action. If auditing only starts after an administrator logs in and runs a script, checks a box, or manually enables a setting, you have not met AU-14(1). ¹

What an assessor will look for: a technical control that is (a) enabled by default, (b) starts at boot, and (c) is hard to disable without detection, plus evidence that you tested those properties. ²

Plain-English interpretation

AU-14(1): system start-up requirement means: the moment a system becomes operational, it must be capable of auditing user sessions in a way that is already “on.” Session auditing commonly includes recording interactive session activity or session metadata (who, when, where, what system), depending on your AU-14 base control design. AU-14(1) adds the boot-time automation requirement: session auditing cannot be optional or delayed. ¹

A practical way to phrase it for engineering tickets:

• “On boot, the session auditing component starts automatically and sends audit output to the approved logging pipeline.”
• “If the component fails to start, we alert and/or fail closed per system criticality and your logging strategy.” ²

Who it applies to (entity and operational context)

Entity types commonly in scope:

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational contexts where AU-14(1) shows up in audits:

• Systems with privileged interactive access (admins, SREs, database operators).
• Jump hosts, bastions, PAM endpoints, and administrative consoles.
• Production systems where incident response depends on session reconstruction.
• Autoscaled or ephemeral compute where “boot” happens frequently (images, containers, VMs). ²

Where teams get surprised: cloud-native environments. “Start-up” includes instance initialization and node replacement events. If your base image does not include the session auditing configuration, you will drift out of compliance each time a new node comes online. ¹

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

1) Define “session audit” for your environment

AU-14(1) is an enhancement; your assessment still needs a clear definition of what you audit. Document:

• In-scope systems (bastions, admin workstations, critical servers).
• Session types (SSH, RDP, console access, web admin consoles, database shells).
• Audit output expectations (session recording vs. session metadata) aligned to your AU-14 control narrative. ²

Deliverable: AU-14/AU-14(1) control statement in your SSP/control catalog that states what “session audits” means internally and where it is required. ¹

2) Choose the boot-time enforcement mechanism per platform

Pick an implementation pattern for each platform class, then standardize it:

Common patterns (choose what fits):

• OS service at boot: A session audit/recording agent runs as a system service that starts automatically and is managed by your configuration management.
• PAM-controlled sessions: Users can only reach target systems through a jump host or PAM that records sessions; the jump host/PAM starts its services at boot.
• Immutable images: Golden images bake in the agent, config, and startup settings so every new node starts compliant.

Deliverable: a platform-by-platform implementation matrix (Windows, Linux, managed Kubernetes nodes, bastions) that maps “start-up mechanism” and “log destination.” ²

3) Make it “default on” and hard to bypass

Assessors probe bypass paths. Close the obvious ones:

• Ensure the service is enabled by default (startup type/enablement at installation).
• Restrict who can stop/disable the service.
• Detect tampering: alert if the service is stopped, disabled, or missing.
• Ensure logs still flow after reboot (network dependencies, certificates, proxy settings). ¹

Deliverable: configuration baseline (GPO, systemd unit settings, agent config, IAM policy) showing enforcement and tamper resistance. ²

4) Validate “start-up” with an assessor-grade test

Do not rely on “it should.” Test and capture outputs:

• Reboot a representative system.
• Confirm the auditing component starts automatically.
• Confirm a session started after reboot is captured and forwarded to the logging destination.
• Repeat for an autoscaled/redeployed instance if you use images or IaC. ¹

Deliverable: test procedure + test record (date, system, steps, screenshots/log excerpts, pass/fail, remediations). ²

5) Operationalize: assign ownership and recurring evidence

AU-14(1) frequently fails in audits because the implementation exists but nobody “owns” ongoing proof. Assign:

• Control owner (Security Engineering or IAM/PAM owner).
• System owners for each in-scope environment.
• Recurring check: service state monitoring, configuration drift checks, and periodic evidence pulls. ¹

Practical tip: Daydream is helpful here as a control operations layer because you can map AU-14(1) to an owner, a procedure, and a recurring evidence list that stays consistent across audit cycles. ¹

Required evidence and artifacts to retain

Retain evidence that proves automatic initiation at start-up, not just that auditing exists.

Minimum evidence set (keep it tight and repeatable):

• Control narrative for AU-14(1) describing how session audits start at boot and on redeploy. ¹
• Configuration proof: service definitions/startup settings, baseline configs, image build scripts, GPO excerpts, IaC modules that enable the service at boot. ²
• System startup logs or service manager logs showing the audit component starts during boot. ¹
• Sample session audit records generated after a reboot (with timestamps) showing collection/forwarding works. ²
• Monitoring/alert rules for agent/service down or log pipeline disruption. ²
• Exception register: any systems not capable of session auditing, with compensating controls and risk acceptance. ²

Common exam/audit questions and hangups

Expect these, and pre-answer them in your evidence pack:

1. “Show me that it starts automatically.” Auditors often ask for a reboot demonstration or boot logs. Have a scripted demo plan and saved results. ¹

2. “What systems are in scope?” If scope is fuzzy, the assessment becomes a scavenger hunt. Provide an inventory slice: bastions/admin entry points and high-risk systems. ²

3. “What happens if the agent fails to start?” Have an operational answer: alerting, incident ticketing, and any access restrictions if session auditing is down. ²

4. “Does this survive redeploy/autoscale?” For cloud environments, show image pipeline or user-data/bootstrap configuration that sets it on every new instance. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AU-14(1)	Fix
Logging enabled only after an admin runs a post-boot script	Not “automatic at system start-up”	Convert to boot-time service enablement in baseline/IaC. 1
Agent installed, but service is “manual” start	Reboot breaks audit continuity	Set service to auto-start; enforce via configuration management. 2
Golden image drift (new instances miss the agent/config)	Autoscaling creates noncompliant nodes	Bake into image pipeline and add drift detection. 2
Session auditing exists on bastion, but admins bypass via direct network paths	Sessions occur without audit coverage	Enforce network segmentation and access paths through audited entry points. 2
Evidence is ad hoc (screenshots from last year)	You cannot prove ongoing operation	Define recurring evidence pulls owned by a named team; track in Daydream. 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement. ¹

Risk still matters operationally. If session auditing does not start at boot, you create blind periods after restarts, patching, scaling, or recovery events. Those are common windows for troubleshooting access and emergency changes, which are exactly the sessions investigators ask about during incident response. AU-14(1) reduces that exposure by requiring deterministic, automatic start-up behavior. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize the requirement)

• Name a control owner and identify in-scope system classes (bastions, admin entry points, critical servers). ²
• Write the AU-14(1) control narrative: “what is a session audit” + “how it starts at boot.” ¹
• Pick one reference implementation per OS/platform and document the startup mechanism. ²

Days 31–60 (implement and prove)

• Implement boot-time enablement in baseline/IaC and roll to a pilot group of systems. ¹
• Create a simple reboot validation test and capture results for each platform. ²
• Add monitoring for audit service down / audit pipeline interruption, and define who responds. ²

Days 61–90 (operationalize and scale)

• Expand to remaining in-scope systems; address exceptions with compensating controls and sign-off. ²
• Establish recurring evidence collection (configs + recent boot/service logs + sample session audit output). ¹
• Track the control in Daydream with mapped owner, procedure, and evidence artifacts so audit prep is a pull, not a scramble. ¹

Frequently Asked Questions

What exactly counts as “system start-up” for AU-14(1)?

Treat it as any event where the system becomes operational: reboot, redeploy from an image, node replacement, or recovery. Your evidence should show session auditing begins automatically after those events. ¹

Do I need full session recording, or is session metadata enough?

AU-14(1) only states that session audits must initiate at start-up; it does not define the depth of capture. Define “session audit” in your AU-14 control narrative, then ensure that defined audit begins automatically at boot. ¹

How do we handle ephemeral cloud instances that come and go?

Put the session auditing enablement in immutable images and/or bootstrap configuration so every new instance starts with auditing already on. Then test by launching a new instance and capturing post-boot session audit output. ²

What evidence is most persuasive to an assessor?

Boot/service manager logs showing the auditing component starts during startup, plus a sample audited session created after the reboot and forwarded to your logging system. Pair that with baseline configuration artifacts that enforce auto-start. ¹

What if the auditing service fails to start because the network logging destination is down?

Decide and document expected behavior (alerting at minimum, and whether access should be restricted until auditing is restored for high-risk systems). Then test and retain evidence of the behavior you chose. ²

How do I keep this from becoming a yearly “audit fire drill” control?

Assign a control owner, define a repeatable evidence list, and schedule recurring checks tied to configuration drift and service health. Daydream can track AU-14(1) ownership, procedures, and recurring artifacts so evidence stays current. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5