AC-20: Use of External Systems

AC-20 requires you to control and document how your workforce accesses and processes your organization’s data from external systems (for example, personal devices, third-party networks, or partner environments), and to align that access with defined trust relationships. You operationalize it by defining what “external system” means for your environment, setting enforceable technical rules, and retaining evidence that access is authorized and governed ¹.

Key takeaways:

• Treat “external systems” as a governed access channel, not a user convenience decision ¹.
• Tie allowed external use to trust relationships and explicit conditions, then enforce them with technical controls and monitoring ².
• Build audit-ready evidence: policy, approvals, configurations, logs, and periodic reviews mapped to AC-20 ¹.

The ac-20: use of external systems requirement sits in the Access Control (AC) family for a reason: the risk is not “devices,” it’s loss of control over identity, session security, data handling, and monitoring when access occurs from systems you do not own or fully manage. “External system” often includes personally owned endpoints (BYOD), home networks, third-party managed devices, partner systems, contractor laptops, and sometimes hosted administrative workstations outside your boundary.

Operators get tripped up because AC-20 is partly governance (trust relationships, authorization, allowed use cases) and partly enforcement (technical mechanisms that make the rule real). Auditors tend to look for two things: (1) you made clear decisions about what is allowed and under what conditions, and (2) you can prove the decision is implemented and reviewed.

This page translates AC-20 into an implementable set of actions: how to define scope, write rules that engineering can enforce, roll out controls such as device compliance gates and managed remote access, and assemble evidence that will survive an assessment against NIST SP 800-53 Rev. 5 ¹.

Regulatory text

NIST states (excerpt): “{{ insert: param, ac-20_odp.01 }} , consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to:” ².

Operator interpretation of the excerpt (what you must do):

1. Define and document trust relationships with other organizations whose systems your users will rely on (for example, partner networks, contractor-managed endpoints, third-party virtual desktop environments) ¹.
2. Specify conditions for authorized individuals to use those external systems to access organizational resources (examples: which users, which data types, which applications, which authentication methods, which device posture requirements) ¹.
3. Make the decision enforceable through access control mechanisms and monitoring so external access is either controlled or blocked, not handled informally ¹.

Plain-English interpretation (what AC-20 is asking you to prove)

AC-20 expects you to run external access like a controlled program:

• You know which external systems are in play.
• You have explicit rules for when access is allowed.
• You enforce those rules with technical controls.
• You review and update the rules as trust relationships and risks change.
• You can produce evidence that the rules are operating ¹.

Who it applies to (entity + operational context)

Entities: Federal information systems and contractor systems handling federal data commonly adopt NIST SP 800-53 controls, including AC-20 ¹.

Operational contexts where AC-20 becomes “real work”:

• Remote workforce: staff access email, code repos, admin consoles, or sensitive data from home or travel networks.
• BYOD or partially managed endpoints: personal laptops/phones used for corporate access.
• Third-party operational support: MSPs, consultants, incident responders, or offshore teams using their own systems.
• Partner connectivity: joint operations, shared platforms, or data exchange where the access originates from a partner-controlled environment.
• Privileged operations: administrators using jump hosts, remote admin tools, or cloud consoles outside a controlled workstation model.

If you have any “we don’t control the device/network” access path to sensitive systems, AC-20 is in scope ¹.

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

1) Define “external system” for your boundary

Create a one-page definition that includes examples relevant to your environment:

• Personally owned endpoints
• Third-party managed endpoints
• Partner networks / shared environments
• Any system outside your authorization boundary used to access organizational systems ¹.

Output: AC-20 scope statement (include inclusions/exclusions and examples).

2) Classify allowed external access by risk tier

Build a simple decision matrix that engineering can implement.

Access scenario	Default stance	Minimum conditions (examples)	Typical control pattern
General business apps (low sensitivity) from external endpoint	Conditional allow	MFA, session timeout, basic device checks	SSO + MFA + conditional access
Sensitive data apps from external endpoint	Restricted	Managed device or VDI, strong MFA, encryption, logging	Device compliance gate or VDI
Privileged/admin access from external endpoint	Highly restricted	Dedicated admin workstation path, just-in-time access, strong monitoring	PAM + bastion/jump + hardened endpoint

You are not required to use these exact tiers, but you do need a rule set that maps risk to conditions and enforcement ¹.

Output: External access standards by system/data sensitivity.

3) Establish trust relationships for third-party-owned systems

For each external organization whose systems will be used, document:

• Who owns/operates the external system
• What access is permitted
• Security requirements (identity assurance, device security expectations, incident notification, monitoring cooperation)
• Offboarding triggers and termination steps ².

This is where third-party risk management connects: you cannot credibly “allow external systems” without documenting the trust basis.

Output: Third-party access addendum language (contract/SOW) or a standardized “external access authorization” record.

4) Make authorization explicit (people + use cases)

Document which roles are permitted to access from external systems, and for what tasks. Common patterns:

• Allow remote access for employees via managed devices.
• Allow contractor access only via company-controlled VDI.
• Prohibit privileged access from unmanaged endpoints; require an approved admin access path ¹.

Output: Role-based external access rules; approvals workflow (ticketing or IAM requests).

5) Implement enforceable technical gates

Pick control points that can actually block noncompliant access:

• Identity controls: SSO, MFA, conditional access rules by app/risk.
• Device posture controls: require device compliance (managed MDM/EDR posture) before granting access.
• Network controls: VPN with device certificates; restrict by IP where appropriate.
• Privileged access controls: PAM, jump hosts, session recording for admin consoles.
• Data controls: DLP for web/email endpoints, restrictions on download/sync from unmanaged devices, encryption requirements ¹.

Operator tip: If your “control” is a policy statement but the app still allows login from any browser on any device, auditors will treat AC-20 as weakly implemented.

Output: Configuration baselines, screenshots/exports of conditional access policies, and system-specific access control settings.

6) Monitor and review external access as a recurring control

Build an operational loop:

• Log and alert on access from unknown devices, geographies, or anomalous networks.
• Periodically review exceptions (who has them, why they still need them, whether conditions are still met).
• Revalidate third-party trust relationships on a set cadence aligned to your TPRM process ¹.

Output: Review reports, exception register, and evidence of follow-up actions.

7) Map ownership, procedure, and evidence so you can prove operation

AC-20 frequently fails on evidence, not intent. Assign:

• Control owner (often IAM lead + GRC)
• Technical owners (IT endpoint, security engineering, PAM)
• Evidence sources (SSO exports, MDM compliance reports, VPN logs, ticket approvals)

Daydream can help by turning this into a control page that ties AC-20 to a named owner, an implementation procedure, and a recurring evidence checklist so you do not rebuild audit readiness each cycle ¹.

Required evidence and artifacts to retain

Keep artifacts that show policy, authorization, and enforcement:

Governance

• External Systems Access Policy / Standard mapped to AC-20 ¹
• Definition of “external system” and scope statement
• Trust relationship documentation for relevant third parties (contracts, addenda, or access authorization forms) ²

Authorization and exceptions

• Role-based access rules for external access
• Exception register (business justification, risk acceptance/approval, expiration, compensating controls)
• Tickets/approvals granting external access exceptions

Technical enforcement

• Conditional access/IAM policy exports (MFA rules, device compliance requirements)
• MDM/endpoint compliance reports that show required controls are enabled
• VPN configuration showing device certificate requirements (if applicable)
• PAM/jump host configuration and session audit logs (for privileged access)

Monitoring and review

• Authentication and access logs demonstrating monitoring for external access patterns
• Periodic access review results and remediation actions

Common exam/audit questions and hangups

1. “What systems are ‘external’ in your environment?” If you cannot define it, you cannot control it.
2. “Show me how you enforce the rule.” Auditors want configuration evidence, not just policy text.
3. “How do you handle third-party access?” Expect scrutiny on trust relationships and offboarding.
4. “How do you prevent privileged access from unmanaged endpoints?” Privileged paths are a high-focus area in access control reviews.
5. “How do you review and expire exceptions?” Exceptions without expirations tend to become permanent.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Writing a policy that bans unmanaged access while allowing it technically.
  Fix: Implement conditional access blocks and test them with a noncompliant device before calling the control “implemented.”

• Mistake: Treating contractors as “employees with different email.”
  Fix: Put contractors behind a controlled access method (VDI/jump host) and tie access to contract dates and offboarding steps.

• Mistake: No trust relationship artifacts.
  Fix: Standardize a third-party external access addendum or access authorization form and require it before provisioning.

• Mistake: Exceptions with no end date.
  Fix: Require expirations and periodic re-approval; disable access automatically when the exception expires.

• Mistake: No control ownership or evidence calendar.
  Fix: Assign an owner and a recurring evidence pull. Daydream-style control mapping is the operational cure: owner, procedure, evidence, cadence ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Operationally, AC-20 failures tend to show up as: unauthorized access paths, weak oversight of third-party access, and inability to reconstruct events because external access was not logged consistently. The risk is amplified where external systems are used for privileged administration or where sensitive data can be downloaded to unmanaged endpoints ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish the “external system” definition and scope.
• Inventory access paths that qualify (remote access, BYOD, contractor access, partner connections).
• Set default rules by sensitivity tier and identify current gaps where enforcement is missing.
• Assign AC-20 owner and evidence sources; create an evidence checklist mapped to the control ¹.

Days 31–60 (enforce and document trust)

• Implement conditional access rules for key systems (at minimum: MFA everywhere; block or constrain unmanaged devices for sensitive apps).
• Stand up or tighten privileged access pathways (PAM/jump host; restrict admin logins from unmanaged endpoints).
• Roll out third-party trust relationship documentation for any external organization with access.
• Create and populate an exceptions register with expirations and approvals.

Days 61–90 (operate and prove)

• Run the first formal review of external access exceptions and third-party access lists; revoke or remediate.
• Validate logging coverage for external access and privileged sessions; confirm you can produce audit-ready exports.
• Conduct a tabletop test: “contractor offboarding” and “lost personal device” access termination paths.
• Convert your implementation into an assessor-friendly control narrative with attached evidence pointers (Daydream can host the mapped procedure and recurring artifacts for AC-20) ¹.

Frequently Asked Questions

Does AC-20 mean we must ban BYOD?

No. AC-20 pushes you to set conditions and enforce them for external systems. Many organizations allow BYOD for low-sensitivity apps with MFA and restrict sensitive or privileged access to managed devices or VDI ¹.

What counts as an “external system” in practice?

Any system outside your authorization boundary used to access your resources can qualify, including personally owned devices, partner systems, and contractor-managed endpoints. Define it explicitly and include concrete examples your teams recognize ¹.

How should we handle third-party (vendor/contractor) access to production?

Require an explicit trust relationship artifact (contract language or access authorization), then force access through controlled mechanisms such as PAM and jump hosts. Keep approvals, session logs, and an offboarding process tied to contract end dates ¹.

What evidence do auditors ask for most often?

They usually ask for the policy/standard, proof of technical enforcement (conditional access/PAM configs), and proof of operation (logs, reviews, and exception handling). If you can’t export or screenshot the enforcement settings, you’ll struggle to prove implementation ¹.

We allow access from partner networks. Do we need a separate agreement?

You need documentation that establishes the trust relationship and the security conditions for access, whether that’s a dedicated agreement, an addendum, or defined terms in an existing contract. The goal is to make the trust basis reviewable and enforceable ².

How do we operationalize AC-20 without creating constant access friction?

Segment by risk: keep low-sensitivity access smoother, and add stronger gates only for sensitive or privileged paths. Most friction comes from unclear rules; publish a simple matrix and align it to enforcement so users get predictable outcomes ¹.

Footnotes

1. NIST SP 800-53 Rev. 5

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