AC-20(1): Limits on Authorized Use

AC-20(1): limits on authorized use requirement means you may allow staff to use an external system (for example, personal devices, partner networks, or third-party platforms) to access your systems or handle your organization-controlled data only after you have explicitly defined, approved, and enforced the conditions for that use. Operationalize it by documenting allowed external systems and use cases, applying technical access restrictions, and keeping durable evidence of approvals and monitoring. ¹

Key takeaways:

• Define “external system” and “organization-controlled information” for your environment, then require documented approval before any use.
• Enforce the decision with technical controls (conditional access, device posture checks, DLP, and session restrictions), not policy alone.
• Keep assessor-ready evidence: inventories, approvals, configurations, logs, and periodic reviews tied to named owners. ²

AC-20(1) sits in the Access Control family and addresses a recurring failure mode: people reach for external systems to “get work done,” then data and access paths sprawl beyond your managed boundary. For federal information systems and contractors handling federal data, the control enhancement requires a gating function: authorized individuals can only use an external system to access your system or to process, store, or transmit organization-controlled information after your organization’s conditions are satisfied. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to implement AC-20(1) is to turn it into a small set of operational decisions: which external systems are permitted, for which roles and data types, under what security conditions, and how you prove those conditions were checked before access was granted. Your auditors will look for two things: (1) clear, bounded authorization criteria; and (2) enforcement evidence showing the criteria are implemented in identity, endpoint, network, and application layers.

This page gives requirement-level implementation guidance you can hand to control owners in IT, security engineering, and system owners to execute quickly and produce evidence that stands up in a NIST SP 800-53 Rev. 5 assessment. ²

Requirement overview (AC-20(1): Limits on Authorized Use)

What the requirement says (plain English)

You may allow a person to use an external system to (a) access your system, or (b) process/store/transmit your organization-controlled information, only after your organization’s preconditions are met. The control is about pre-authorization and enforceable constraints, not “trusting employees to behave.” ¹

Why assessors care

External systems create:

• Unmanaged identity contexts (accounts outside your IdP and logging stack)
• Weaker endpoint controls (personal laptops, unmanaged mobile devices)
• Data residency and retention risks (data copied into third-party clouds)
• Harder incident response (limited telemetry, slower access revocation)

AC-20(1) is how you show you made deliberate, enforceable decisions about those risks.

Regulatory text

“Permit authorized individuals to use an external system to access the system or to process, store, or transmit organization-controlled information only after:” ¹

Operator meaning: You must define the “only after” conditions (the gating criteria), then implement them as a real approval-and-enforcement workflow. If you cannot prove the conditions were met before access or data handling occurred, the control will fail in practice even if a policy exists. ²

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 Rev. 5 controls. ²
• Contractor systems handling federal data, including environments where federal information is processed, stored, or transmitted. ¹

Operational scope (where this shows up)

• BYOD or personally-owned endpoints accessing corporate SaaS
• Third-party collaboration tools (chat, file sharing, ticketing) used to handle controlled data
• External networks (home networks, partner networks, public Wi‑Fi) used for access
• Admin access from non-corporate devices
• Contractors accessing systems from their employer-managed laptops

If a system or platform is not owned/managed under your security program, treat it as “external” until you formally decide otherwise.

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

Step 1: Define what counts as “external system” in your environment

Create a short definition in your access control standard that covers:

• Personally owned devices
• Third-party operated SaaS where your security team does not control baseline configurations
• Partner networks and contractor corporate endpoints
• Any environment where you cannot guarantee your required logging, patching, and configuration baselines

Deliverable: “External System Definition” section in your Access Control Standard mapped to AC-20(1). ²

Step 2: Classify “organization-controlled information” for the purpose of external use

You need an operational rule that a system owner can apply quickly. Common approaches:

• Map to your data classification policy (e.g., Public / Internal / Controlled / Restricted)
• Identify “never external” categories (regulated data, credentials, security logs, sensitive federal information)

Deliverable: Data handling matrix showing which data classes may be processed/stored/transmitted via approved external systems and which are prohibited.

Step 3: Establish explicit authorization conditions (“only after” criteria)

Write criteria that can be enforced. Keep them concrete:

• Identity conditions: SSO required; MFA required; no shared accounts; approved roles only
• Device conditions: device managed (MDM/EDR enrolled); disk encryption; screen lock; patch level; no jailbroken/rooted devices
• Network/session conditions: VPN required for certain apps; geolocation restrictions; session timeout; step-up auth for admin
• Data controls: DLP rules; download blocked for sensitive repositories; watermarking; copy/paste controls; external sharing disabled
• Monitoring conditions: logs centralized; alerts for impossible travel, risky sign-ins, mass download

Deliverable: AC-20(1) “External System Access Conditions” standard plus an exception path with compensating controls. ¹

Step 4: Build an approval workflow tied to system and data owners

Policy without a workflow becomes informal approvals in chat. Implement a lightweight gate:

1. Requestor states external system, use case, data class, and roles.
2. System owner confirms business need and least privilege.
3. Security reviews conditions (device posture, logging, DLP, tenant settings).
4. Compliance/GRC validates evidence retention expectations.
5. Access is enabled only after approvals and configurations are complete.

Tip: If you already run third-party due diligence, connect the external system approval to that process so the “external system” is assessed before it is authorized for controlled data.

Deliverable: Ticket template (or GRC workflow) that captures the “only after” approvals and required configuration checks.

Step 5: Enforce with technical controls (make it hard to bypass)

Assessors will test for bypass paths. Prioritize:

• Conditional access: block unmanaged devices; require compliant device for sensitive apps
• App controls: restrict OAuth scopes; ban personal email domains for invites; disable public links
• Endpoint controls: MDM enrollment required to access mail/files; EDR installed
• Network controls: restrict admin interfaces to managed jump hosts
• CASB/DLP where applicable to prevent exfiltration to unapproved external systems

Deliverable: Configuration snapshots and change records showing enforcement aligned to the written conditions.

Step 6: Continuous verification and periodic re-authorization

External systems change. Build an operating cadence:

• Review authorized external systems list when services are added or major configurations change
• Revalidate high-risk access paths (admin access, sensitive repositories)
• Confirm logging continues to reach your SIEM and alerts are functioning

Deliverable: Review records, access recertifications, and monitoring health checks mapped to AC-20(1).

Required evidence and artifacts to retain

Keep evidence that shows definition, approval, enforcement, and monitoring:

Evidence	What it proves	Owner
External systems inventory (authorized list + prohibited list)	You bounded “external system” use cases	GRC / Security
Data handling matrix for external systems	You controlled data processing/storage/transmission	Data owner / GRC
Approval tickets / workflow records	“Only after” authorization happened	System owner
Conditional access and device compliance configs (exports/screenshots)	Enforcement exists and matches criteria	IAM / Endpoint
SaaS tenant configuration baselines (sharing, OAuth, retention)	External system is configured to your requirements	App owner
Centralized logs and alert rules; sample alerts	Monitoring conditions are met	SecOps
Exception register with compensating controls	Risk accepted explicitly, not by accident	GRC / Risk

If you use Daydream to manage control-to-evidence mapping, set AC-20(1) with a named control owner, an implementation procedure, and a recurring evidence checklist so collection does not depend on tribal knowledge. ¹

Common exam/audit questions and hangups

• “Show me which external systems are authorized for controlled information.” Auditors want a list, not a paragraph.
• “How do you prevent access from unmanaged devices?” They will look for conditional access policies and exceptions.
• “What happens if someone uses an unapproved external system anyway?” Have detective controls (CASB/DLP alerts) and an incident/runbook response.
• “How do you ensure approvals happen before access is granted?” Show workflow timestamps and access provisioning logs.
• “Define ‘organization-controlled information’.” If your definition is fuzzy, your scope becomes untestable.

Frequent implementation mistakes (and how to avoid them)

1. Relying on an Acceptable Use Policy as the control. Fix: implement conditional access/device posture checks so violations are blocked or detected.
2. No shared definition of “external system.” Fix: publish a definition and train system owners on classification and gating.
3. Approvals happen, but evidence is scattered. Fix: one workflow system of record; attach config exports and approvals to the same ticket.
4. “Approved external system” with insecure default settings. Fix: create SaaS configuration baselines (sharing disabled by default, OAuth app allowlist, logging enabled).
5. Exceptions become permanent. Fix: require compensating controls and time-bound review in an exception register.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list enforcement actions. Your practical risk remains straightforward: if an external system becomes a path for unauthorized access or data exposure, you will struggle to show preventive controls and “only after” authorization. ²

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

First 30 days (stabilize and define)

• Name the AC-20(1) control owner and system-owner responsibilities. ²
• Draft and approve: external system definition, data classes in scope, and authorization conditions.
• Stand up the approval workflow template and an initial authorized external systems list.
• Identify top external access paths (email, file storage, admin consoles) and document current enforcement gaps.

Days 31–60 (enforce and evidence)

• Implement conditional access baselines for the highest-risk apps and admin paths.
• Configure SaaS tenant restrictions (sharing, OAuth allowlists, logging) for approved external systems.
• Centralize logs needed to prove enforcement and detection; validate alerting for risky sign-ins and mass downloads.
• Run a tabletop test: request an external system approval, complete the workflow, and confirm evidence is assessor-ready.

Days 61–90 (operate and scale)

• Expand enforcement to additional applications and data repositories.
• Launch periodic access reviews for external-system-enabled roles (contractors, admins, privileged users).
• Operationalize exceptions: register, compensating controls, and re-approval triggers.
• In Daydream, map AC-20(1) to recurring evidence artifacts so collection is repeatable across audit cycles. ¹

Frequently Asked Questions

What counts as an “external system” for AC-20(1)?

Treat any system, device, or network outside your managed security boundary as external until you formally authorize it. That includes personal devices, partner environments, and third-party SaaS you do not administer.

Does AC-20(1) prohibit BYOD?

No. It requires you to permit BYOD access only after your defined conditions are met and enforced. Many organizations allow BYOD for low-risk access while blocking sensitive apps unless the device is managed.

How do we prove “only after” in an audit?

Show a workflow record with approvals and timestamps, then show access provisioning or conditional access rules that enforce the decision. Pair that with configuration exports and logs demonstrating the controls operate as written.

What if a business unit signs up for a SaaS tool without security approval?

Treat it as an unapproved external system and block integrations or access where possible, then route it through your external-system authorization workflow. Add detective controls to find new SaaS (for example, SSO app catalogs or network discovery) and open remediation tickets.

Are contractors covered by AC-20(1)?

Yes, if they are authorized individuals accessing your system or handling your organization-controlled information via their own employer-managed endpoints or other external systems. Your conditions should explicitly address contractor endpoints and logging.

Where does third-party risk management fit?

If the external system is operated by a third party, the authorization decision should depend on third-party due diligence outcomes and contractual requirements. Tie the AC-20(1) approval to your third-party onboarding or renewal process so the “only after” gate is real.

Footnotes

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

2. NIST SP 800-53 Rev. 5