AC-9(3): Notification of Account Changes

Compliance teams often treat AC-9 as a “login banner” control and stop there. AC-9(3) is narrower and more operational: it is a user-facing notification that something about the account changed recently, presented after the user successfully authenticates. The control’s value is straightforward: if an attacker (or an admin mistake) changes a user’s privileges, MFA methods, password, recovery channels, or other sensitive account properties, the user gets a near-immediate signal the next time they log in and can report it.

For a CCO, Compliance Officer, or GRC lead, the hard part is not the concept. The hard part is turning the requirement’s two open parameters into something testable, then proving to an assessor that your implementation is complete across the environments that matter (workforce identity, privileged access, and key business applications). This page gives requirement-level implementation guidance you can hand to IAM and application owners, with an evidence plan that makes audits predictable.

Target keyword: ac-9(3): notification of account changes requirement

Requirement: AC-9(3) Notification of Account Changes (what it means)

AC-9(3) requires you to notify the user, upon successful logon, of changes to defined account attributes that occurred within a defined time period. The control text is parameterized, so you must set and document two decisions:

1. what “account changes” are in scope, and
2. the time window you will look back for changes. ¹

This is not an administrative alert to a SOC mailbox. It is a user-visible, post-authentication message.

Plain-English interpretation

When a user logs in, your system must tell them: “Something about your account changed recently.” The notice should be specific enough to be useful (what changed, and when) without disclosing sensitive details to an attacker. The notice needs to be driven by a trustworthy source of record (IdP directory events, PAM events, or application audit events), not a manual process.

Regulatory text

“Notify the user, upon successful logon, of changes to [organization-defined account changes] during [organization-defined time period].” ¹

Operator translation: you must (a) define the triggering changes and lookback period, (b) implement a mechanism that detects those changes per account, and (c) display the notice after the user successfully authenticates.

Who it applies to (entity and operational context)

AC-9(3) commonly applies where you align to NIST SP 800-53 for:

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

Operationally, treat AC-9(3) as applicable to:

• Workforce identity (SSO/IdP accounts, directory accounts)
• Privileged accounts (PAM-managed, break-glass, admin roles)
• High-impact applications that maintain local accounts or local role assignments
• Remote access entry points (VPN, VDI, bastions) if they have distinct account profiles

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

Step 1: Set the two parameters (make them auditable)

Document:

• In-scope account changes (your list)
• Lookback period (your chosen window)

A pragmatic scoping list to start with (tailor to your environment):

• Password change or reset
• MFA method enrollment/removal or factor reset
• Email/phone/recovery channel change
• Role/group membership change (especially admin or privileged groups)
• Account enable/disable, unlock events
• Privileged elevation approvals (if your model grants time-bound admin)
• Changes to federation/SSO bindings that impact authentication behavior

Keep the list short enough that you can implement it consistently across systems, and broad enough to cover security-significant changes.

Step 2: Identify your system of record for “account change events”

Pick the authoritative event source per account population:

• For SSO-first environments: IdP audit/event logs (directory + authentication platform)
• For privileged access: PAM audit trails and role grant logs
• For applications with local accounts: application audit logs or database audit tables

Your design goal: a deterministic way to answer, at login time, “Did any defined account change happen for this identity within the lookback window?”

Step 3: Choose an implementation pattern

Use one of these patterns (or a hybrid):

Pattern A: Native IdP post-login notification
If your identity platform supports post-authentication messaging based on profile flags or events, implement the notice there so it covers many apps via SSO.

Pattern B: Application-level post-login notification
If the application owns account state (local roles, local MFA, local password), implement the notice in the app after authentication succeeds.

Pattern C: Central “account change ledger”
Write account change events into a centralized table/stream keyed by immutable user identifier, then query it at login. This pattern helps when multiple systems can change account attributes.

Step 4: Implement the notice UX (security and usability)

Your notification should be:

• Post-authentication only (do not show on failed logons)
• Bound to the authenticated identity
• Actionable: include a help link or instructions to report unexpected changes

Recommended content elements:

• A simple message (“Your account settings changed recently.”)
• The change category (e.g., “MFA method updated”, “Role membership changed”)
• A timestamp (or date) of the most recent change
• A “Report this” route (service desk ticket, security mailbox, or in-app workflow)

Avoid exposing details that create risk (for example, listing the new email address in full if your threat model includes session hijacking after login).

Step 5: Prevent gaps (edge cases you must cover)

Account changes can happen without the user logging in for a while. Your design must still notify at the next successful logon.

Common edge cases:

• Admin changes group membership, but the notice logic only watches password events
• Changes occur in a downstream directory but the IdP notice reads from a different log source
• Privileged and standard accounts share an identifier and your system conflates them
• Service accounts and API accounts (non-interactive) cannot “log on” in a way that shows a notice

For non-interactive accounts, document an exception rationale and compensating controls, or route notifications to account owners if your program requires it. Keep the decision consistent with your overall AC control narrative.

Step 6: Operationalize ownership and recurrence

Assign:

• Control owner: typically IAM lead or security engineering
• Operators: IdP admin, PAM admin, and application owners
• GRC role: evidence collection cadence and control attestation

Daydream can help here by turning AC-9(3) into a mapped control record with named owners, implementation procedure, and recurring evidence tasks so you are not rebuilding the evidence pack each audit cycle. ¹

Required evidence and artifacts to retain

Assessors will look for proof of design, implementation, and operation.

Retain:

• Parameter decisions: documented list of in-scope account changes + defined lookback period
• Implementation procedure: how notices are generated, what log source is authoritative, and where the code/config lives
• Configuration exports: IdP/PAM/app settings showing the feature is enabled
• Screenshots or screen recordings: a successful logon showing the notice
• Test cases: scripted steps (change MFA, change role, log in, observe notice)
• Log extracts: account change event record plus authentication event correlated to a notification event (where available)
• Exception register entries: for accounts/systems where post-login notice is infeasible, with compensating controls and approvals

Common exam/audit questions and hangups (what auditors ask)

Expect questions like:

• “What account changes trigger notification, and where is that defined?” ¹
• “Show me the notification at successful logon for a real change event.” ¹
• “How do you know it works for privileged accounts and not just normal workforce users?”
• “What happens if an admin changes a user’s role while the user is inactive?”
• “What systems are in scope, and what are documented exceptions?”

Hangups you can prevent:

• Evidence that only shows a generic login banner (that supports AC-9, but may not satisfy AC-9(3))
• Notifications that are email-based rather than post-login
• “We rely on users noticing UI differences” with no explicit notice mechanism

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-9(3)	Fix
Only a static login banner	No account-change content	Add event-driven messaging tied to recent account changes. 1
Email alerts instead of post-login	Control text requires notice “upon successful logon”	Keep emails as a supplement, but implement the on-login notice. 1
No parameter documentation	Assessor cannot test “defined changes” or “defined time period”	Publish the parameter list and lookback window in your control narrative. 1
Watches only password resets	Misses privilege/MFA/recovery changes	Expand event coverage to your defined list, especially MFA and role changes.
No correlation evidence	Hard to prove notice is triggered by real events	Keep a test record: change event ID, login event, screenshot, and timestamp alignment.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so treat AC-9(3) as an assessment and authorization readiness control rather than a control with a specific penalty narrative here.

Risk-wise, AC-9(3) reduces dwell time for account takeover and admin error by pushing detection to the user at the moment they can act. The practical compliance risk is simpler: if you cannot show the notice firing for real account changes, an assessor can reasonably mark the enhancement unmet based on the plain language of the requirement. ¹

Practical execution plan (30/60/90-day)

You asked for a fast operational plan. Use phases to match your engineering throughput.

First 30 days (design + scoping)

• Confirm systems in scope: IdP, PAM, top business apps with local auth.
• Define “account changes” list and lookback period; get IAM + security approval.
• Decide the implementation pattern per system (IdP-native vs app-native vs central ledger).
• Draft the evidence checklist and test scripts; align with your assessor’s expectations.

Days 31–60 (build + pilot)

• Implement for the highest-coverage control point (usually IdP post-login).
• Implement for privileged access paths (PAM or admin portals).
• Run pilot tests with a small user group, including at least one privileged user scenario.
• Start collecting evidence artifacts as you test so you do not recreate them later.

Days 61–90 (expand + operationalize)

• Extend to remaining in-scope applications with local accounts.
• Add monitoring for failures (notification service down, event feed delays).
• Finalize exceptions with compensating controls and approvals.
• In Daydream, map AC-9(3) to the control owner, procedure, and recurring evidence artifacts so the control stays “audit-ready” after the initial rollout. ¹

Frequently Asked Questions

Do we have to show the notification on every login, even if nothing changed?

AC-9(3) is triggered by changes within your defined window, so design it to show only when a relevant change exists. Document the logic so an assessor can test both “change happened” and “no change” scenarios. ¹

Can we meet AC-9(3) by emailing users about account changes?

Email can help, but the requirement calls for notifying the user “upon successful logon.” Keep email as a supplement and implement an in-product post-login notice to satisfy the requirement text. ¹

What counts as an “account change”?

The control is parameterized, so you define it. Most programs include password resets, MFA changes, recovery info changes, and role/group membership changes because they affect authentication strength or authorization. ¹

How do we handle service accounts that never interactively log in?

Document them as out of scope for “user upon successful logon” notice, and record compensating controls (owner notifications, tighter change control, or enhanced monitoring). Keep the rationale and approvals in your exception register.

Our IdP can show a generic “profile updated” message but not the exact change. Is that acceptable?

It can be acceptable if the message is clearly tied to defined account changes within the defined time period and is shown upon successful logon. If you cannot make it specific, strengthen your evidence with test cases showing the notice appears after each in-scope change type. ¹

What evidence is strongest for auditors?

A reproducible test: make an in-scope account change, capture the change event record, log in successfully, and capture the notification plus timestamps. Pair that with configuration exports and your documented parameter decisions. ¹

Footnotes

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