AC-2(11): Usage Conditions

AC-2 is the NIST 800-53 family for account management, and enhancement (11) focuses on “usage conditions.” In practice, this requirement exists because many breaches and audit findings trace back to accounts being used outside their intended boundaries: service accounts used interactively, admin accounts used for email, contractors logging in from unmanaged devices, or privileged access used outside approved hours. AC-2(11) forces you to turn those expectations into enforceable, testable rules.

The challenge is that the NIST control text is parameterized. Your job as a CCO, GRC lead, or control owner is to fill in those parameters: (1) what usage conditions you require, and (2) which accounts (or account categories) those conditions apply to. Then you must show you enforce them consistently across your environment, including third-party hosted systems if they are in scope.

This page gives requirement-level implementation guidance you can execute quickly: scoping, control design, step-by-step implementation, evidence to retain, and the audit questions that tend to break teams when AC-2(11) is tested. ¹

Regulatory text

Requirement (AC-2(11)): “Enforce {{ insert: param, ac-02.11_odp.01 }} for {{ insert: param, ac-02.11_odp.02 }}.” ²

Operator interpretation of the parameters

Because the requirement is parameterized, you must define both parts:

• ac-02.11_odp.01 (the “usage conditions”): The explicit rules that constrain account use. Examples include:

  • Allowed authentication methods (SSO only, phishing-resistant MFA, no basic auth)
  • Allowed device posture (managed device required, EDR present, disk encryption)
  • Allowed networks/locations (corporate VPN, specific IP ranges, geo restrictions)
  • Allowed time windows (maintenance windows for break-glass or service operations)
  • Allowed session characteristics (no interactive login for service accounts; session timeout)
  • Allowed roles/actions (admin accounts only for admin tasks; no email/browsing)

• ac-02.11_odp.02 (the accounts in scope): The account populations that must follow those conditions. Common scoping choices:

  • Privileged/admin accounts
  • Service accounts and workload identities
  • Remote access accounts
  • Third-party/contractor accounts
  • Break-glass/emergency accounts

What “enforce” means

Auditors and assessors generally expect preventive technical enforcement where feasible: conditional access, PAM controls, endpoint compliance gating, network restrictions, and configuration controls that block nonconforming access. Policy-only statements do not satisfy “enforce” if the system still allows prohibited usage. ¹

Plain-English requirement meaning (what you must be able to prove)

You must be able to answer, with evidence:

1. What are the allowed ways accounts may be used?
2. Which accounts have those restrictions?
3. Where are those restrictions enforced technically?
4. How do you handle exceptions without breaking control intent?
5. How do you confirm the control keeps working over time?

If you cannot show clear ownership, operating cadence, and traceable evidence, this control often fails in audits even when security tooling exists. ¹

Who it applies to

Entity scope

AC-2(11) commonly applies to:

• Federal information systems and programs aligned to NIST SP 800-53
• Federal contractors and service organizations handling federal data or operating federal systems
• Service providers expected to align to NIST 800-53 through customer requirements ¹

Operational context (where it shows up)

• Central IAM (IdP, directory services)
• Privileged access management (PAM) and admin workflows
• Endpoint management and device compliance
• VPN/remote access and network segmentation
• Cloud access patterns (console access, API keys, workload identities)
• Third-party access paths (support portals, jump hosts, federated access)

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

Step 1: Create the “AC-2(11) control card” (make it runnable)

Create a one-page control card that a control operator can run without interpretation:

• Objective: enforce defined usage conditions for defined account populations
• Owner: named role (IAM lead, security engineering, or GRC control owner)
• In-scope systems: IdP, PAM, endpoint platform, VPN, cloud IAM
• Trigger events: new account class, new app onboarding, exception request, quarterly review
• Enforcement points: list each tool/config that enforces a condition
• Exceptions: who can approve, duration, compensating controls, logging requirements ¹

This is the fastest way to prevent “policy exists but nobody runs it” failures.

Step 2: Define usage conditions by account category (keep it crisp)

Build a matrix. Do not start from tools; start from account intent.

Example usage-conditions matrix (template)

Account category	Allowed login type	Device requirement	Network/location	MFA	Special rules
Privileged admin	Interactive only via approved admin workflow	Managed, compliant	VPN or trusted network	Strong MFA	No email/browsing; separate admin identity
Standard workforce	Interactive	Managed preferred (or defined BYOD policy)	Normal	MFA	Block legacy auth
Service accounts	Non-interactive only	N/A	Restricted to workloads	Key/cert controls	No console sign-in; rotate secrets
Third-party support	Interactive via federated access	Managed or VDI	Restricted	MFA	Time-bound access; ticket required
Break-glass	Emergency only	Defined	Defined	Strong MFA	Stored in vault; use requires incident record

Your matrix becomes your “ac-02.11_odp.01” and “ac-02.11_odp.02” definition set. ²

Step 3: Map each condition to a technical enforcement mechanism

For each row in the matrix, identify the enforcing control and the evidence source:

• Conditional access policies (device compliance, geo/IP rules, sign-in risk)
• PAM policies (approved pathways for admin actions, session controls)
• Directory/IAM restrictions (deny legacy auth, restrict group membership)
• Service account controls (deny interactive login, workload identity constraints)
• Network controls (jump hosts, segmentation, allowlists)
• Logging/monitoring (SIEM alerts for attempted violations)

Write the mapping down. Audits fail when enforcement is “tribal knowledge.”

Step 4: Implement and test enforcement (prove it blocks)

For each usage condition:

• Implement the control in the enforcing platform.
• Perform a negative test: attempt a prohibited access path and confirm it is blocked.
• Record the test results and keep screenshots/log exports.

Testing matters because “configured” is not the same as “effective,” especially with policy ordering, exclusions, and inherited settings.

Step 5: Build an exception process that does not hollow out enforcement

Exceptions will happen. The control breaks when exceptions become the default.

Minimum exception rules:

• Written business justification
• Time-bound approval with owner
• Compensating controls (additional monitoring, narrowed scope, ticket linkage)
• Post-expiration review to remove the exception

Track exceptions like risk acceptances. If your IAM tool has exclusion groups, treat membership as controlled configuration with approvals.

Step 6: Run control health checks (sustained operation)

Add a recurring check that verifies:

• In-scope accounts are still correctly categorized
• Enforcement policies still exist and have not been weakened
• Exclusions are reviewed
• New apps inherit the intended conditions
• Break-glass accounts are intact and monitored ¹

Daydream (as a GRC workflow layer) fits naturally here: it can store the control card, tie enforcement configurations to evidence requests, and track exceptions and remediation items through validated closure without turning AC-2(11) into a spreadsheet exercise.

Required evidence and artifacts to retain (minimum evidence bundle)

Keep evidence that proves definition, implementation, and operation:

1. Defined usage conditions + scope

   • Approved policy or standard defining usage conditions by account type
   • Account inventory or list of in-scope account categories and how accounts are tagged

2. Enforcement configuration evidence

   • Conditional access / IAM policy exports or screenshots
   • PAM policy configuration and session controls
   • Service account configuration proving “no interactive login” where applicable

3. Testing evidence

   • Test scripts or test cases (negative tests)
   • Logs showing blocked attempts and policy evaluation outcomes

4. Exception handling

   • Exception requests, approvals, expiration dates, and compensating controls
   • Review records showing exceptions were removed or renewed with justification

5. Ongoing operation

   • Control health check checklist and results
   • Remediation tickets with closure evidence ¹

Common exam/audit questions and hangups

Expect these, and prepare your evidence to answer them fast:

• “Show me your defined usage conditions. Where are they approved?”
• “Which account populations are subject to which conditions?”
• “Prove enforcement: what happens if a service account tries to log in interactively?”
• “Where are the exclusions? Who approved them?”
• “How do you ensure new applications and new accounts inherit the right conditions?”
• “How do you detect drift in conditional access policies over time?” ¹

Hangup: teams demonstrate a strong written policy but cannot show the technical enforcement artifacts, or cannot show that enforcement applies to the full in-scope account population.

Frequent implementation mistakes (and how to avoid them)

1. Writing “usage conditions” as vague policy language

   • Fix: write conditions as enforceable rules (“managed device required,” “deny legacy auth,” “service accounts non-interactive”).

2. Scoping too broadly without account classification

   • Fix: define account categories and tagging rules first; then attach policies to tags/groups.

3. Relying on monitoring instead of prevention

   • Fix: implement blocks where feasible; keep monitoring as a backstop.

4. Exception groups becoming permanent

   • Fix: require expirations, periodic review, and a compensating control list.

5. No control health check

   • Fix: run recurring checks and tie findings to tracked remediation items with due dates. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source material, so treat AC-2(11) as an assessor-driven and customer-driven expectation rather than a control with a specific cited enforcement pattern here.

Risk-wise, weak usage conditions increase the chance that a compromised credential becomes an incident. They also expand blast radius: privileged accounts used casually, service accounts used interactively, and third-party access without constraints. For regulated environments, the business impact often shows up first as an audit finding: inability to demonstrate control operation, uncontrolled exceptions, and inconsistent enforcement across systems. ¹

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

Time-boxing is useful, but avoid calendar promises you cannot meet. Use phases.

Days 0–30: Define and scope

• Appoint the control owner and publish the AC-2(11) control card.
• Inventory account categories and decide which are in scope for AC-2(11).
• Draft the usage-conditions matrix and get approval from security + system owners.
• Identify enforcement points per condition (IdP, PAM, endpoint, VPN, cloud IAM). ¹

Days 31–60: Implement enforcement + exception workflow

• Configure conditional access / IAM policies aligned to the matrix.
• Implement admin separation patterns and service account restrictions.
• Stand up an exception request and approval flow with expirations and tracking.
• Produce initial evidence bundle (policy, configs, scope mapping). ¹

Days 61–90: Test, prove, and operationalize

• Run negative tests for each condition and capture results.
• Create a control health check checklist and schedule recurring reviews.
• Tune monitoring for attempted violations and exception usage.
• Track remediation items to closure and store evidence centrally (Daydream can manage the evidence workflow and reminders). ¹

Frequently Asked Questions

What counts as “usage conditions” for AC-2(11)?

Usage conditions are explicit, testable constraints on how an account can be used (for example, allowed authentication methods, device posture, network/location, and whether interactive login is permitted). Define them by account category and make sure each condition maps to a technical enforcement point. ²

Do I need to enforce usage conditions for every account?

The control is parameterized, so you define which account populations are in scope. In audits, privileged accounts, service accounts, remote access, and third-party access are common high-scrutiny categories. ²

Is a written policy enough if we monitor violations?

“Enforce” generally requires preventive controls where feasible, not only detective monitoring. Keep monitoring, but pair it with blocks such as conditional access and PAM restrictions. ¹

How do we handle legacy systems that can’t support conditional access?

Document an exception with a compensating control plan, such as access through a controlled jump host, tighter network allowlists, and enhanced logging tied to tickets. Track the exception to a remediation plan so it does not become permanent. ¹

What evidence will an assessor ask for first?

Expect requests for the usage-conditions definition, enforcement configurations (exports/screenshots), and proof tests showing blocked prohibited access. Also expect a list of exceptions and who approved them. ¹

How should we operationalize this across third parties (contractors, support providers)?

Put third-party identities into a distinct account category, require federated access where possible, and enforce tighter conditions (restricted networks, time-bound access, ticket-based approvals). Keep the access method and enforcement artifacts in your evidence bundle. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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