Use of External Systems

To meet the FedRAMP “Use of External Systems” requirement (NIST SP 800-53 Rev 5 AC-20), you must set and enforce documented terms and conditions for any external system that can access your authorized system boundary, including third-party-managed endpoints and federated/connected environments. Operationally, this means defining approval, technical guardrails, periodic review, and revocation for external access paths, and keeping evidence. ¹

Key takeaways:

• Write explicit terms for each external system access scenario (remote endpoints, partner networks, federated identity, managed service access).
• Enforce the terms with technical controls (network restrictions, strong authentication, device posture, session controls) tied to approvals.
• Keep auditor-ready evidence: requests, approvals, configurations, review results, and exception records. ¹

“External systems” is broader than “remote users.” For AC-20, external systems include any system not under your direct authorization boundary control that can reach into your FedRAMP-authorized environment: personal devices, contractor laptops managed by a third party, partner networks, external identity providers, jump hosts, and support tooling operated by another organization.

AC-20 is tested as both a governance control and a technical reality check. Assessors will look for clear terms and conditions that match the trust relationship you have (or claim to have) with the other organization, and they will validate that your environment actually enforces those terms. If your policy says “only managed devices,” but you cannot prove device posture or you allow broad VPN access, you will struggle in assessment and ongoing monitoring because access decisions become hard to justify and hard to reproduce.

The fastest way to operationalize AC-20 is to treat each external access path as a managed “access product” with (1) a defined use case, (2) required controls, (3) an approval workflow, (4) logging and review, and (5) a clean offboarding trigger. FedRAMP documentation templates help you structure and present this in authorization packages. ²

Regulatory text

Requirement (AC-20): “Establish terms and conditions consistent with any trust relationships established with other organizations owning, operating, or maintaining external systems, allowing authorized individuals to access the system from external systems.” ¹

What the operator must do

You must do two things, and both must be true:

1. Define the terms and conditions for access from external systems, and make them consistent with the trust relationship (for example, contractor company-managed laptops vs. unknown personal devices).
2. Allow access only for authorized individuals under those terms, with controls that make the terms enforceable and auditable. ¹

---

Plain-English interpretation (what AC-20 is really testing)

AC-20 asks: “If someone is coming in from outside your managed environment, what conditions must be true before they can touch systems in the authorization boundary, and how do you prove you enforced those conditions?”

Your terms and conditions should answer, without ambiguity:

• What external systems are permitted (and which are prohibited)?
• What security posture is required (identity strength, device management, network location, encryption, patching expectations)?
• What access methods are approved (VPN, ZTNA, VDI, bastion, API, federated SSO)?
• Who can approve, who provisions, and who reviews?
• What telemetry proves compliance (logs, device posture reports, identity logs)?
• What happens when trust changes (contract ends, device is lost, third party changes control ownership)? ¹

---

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs) operating a FedRAMP-authorized cloud service offering (CSO) and its authorization boundary.
• Federal Agencies sponsoring or operating systems where external access paths exist and must align with the authorized baseline. ¹

Operational contexts that commonly fall under AC-20:

• Workforce access from home networks to admin consoles or production systems
• Contractor/third-party support access (including “break glass” support)
• Managed service provider access to your tenant or infrastructure tooling
• Federation with an external identity provider (agency IdP, partner IdP)
• Partner or customer connectivity into APIs or private endpoints
• Use of external jump hosts, remote support tools, or monitoring platforms operated by a third party

---

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

Step 1: Inventory external system access paths (make it concrete)

Create a single inventory that lists every way an external system can reach the boundary:

• Access method (SSO, VPN, ZTNA, VDI, bastion, API, support tool)
• Entry point (public endpoint, private link, admin portal, management plane)
• External system owner/operator (employee device, contractor company, third party)
• User population (admins, engineers, support, auditors)
• Data/actions reachable (read-only logs vs. privileged changes)

Output artifact: External Access Path Register (table format is fine).

Step 2: Define “terms and conditions” per access scenario

Write terms that match the trust relationship. Don’t write one generic policy and hope it covers everything. For each access scenario, define:

• Eligibility: which roles and which business justification qualifies
• Identity requirements: MFA type, conditional access, privileged access workflows
• Device requirements: managed device only, endpoint detection and response, disk encryption, minimum OS posture (state what you verify, not what you “expect”)
• Network requirements: allowed countries, IP allowlists, private connectivity, segmentation, no direct admin access from public internet where avoidable
• Session requirements: timeouts, re-auth, step-up for privileged actions
• Logging: what is logged and where it is reviewed
• Revocation triggers: contract end, role change, detected compromise, device noncompliance

Output artifacts:

• Use of External Systems Standard (policy-level)
• External Access Terms Matrix (scenario-by-scenario terms)

Step 3: Map terms to enforceable technical controls

Assessors will test whether your terms are enforced. Build a mapping from each term to the configuration that enforces it:

• Conditional access policies
• MFA enforcement and phishing-resistant methods where required by your risk decision
• Device compliance checks via MDM/EDR integration
• Network segmentation, bastion hosts, private endpoints
• Privileged access management (PAM) for admin entry
• API gateways and mTLS/OAuth controls for system-to-system access
• Central logging and alerting

Output artifact: AC-20 Control-to-Config Mapping (include screenshots or config exports as evidence).

Step 4: Implement an approval + provisioning workflow

Define a workflow that cannot be bypassed:

• Request intake (ticket) with business justification and scope
• Approver(s): system owner + security (and agency sponsor if applicable)
• Provisioning steps: group assignment, policy attachment, credential issuance
• Time-bounded access for elevated roles where feasible
• Offboarding: automatic removal tied to HR/contractor end dates where possible

Output artifacts:

• Access request tickets
• Approval records
• Provisioning logs (IdP group changes, PAM grants)

Step 5: Set a review cadence and run access reviews

AC-20 expects periodic revalidation in practice, even though the excerpt focuses on terms and conditions. Define:

• What gets reviewed (external access groups, federated trust, third-party accounts, support tooling)
• Who reviews (system owner, security)
• What constitutes “still valid” (active contract, current role, device compliant)
• What happens to exceptions

Output artifacts:

• Access review reports
• Reviewer sign-off
• Remediation tickets for removals and fixes

Step 6: Define and manage exceptions

You will have edge cases (emergency support, specialized tooling, agency constraints). Make exceptions auditable:

• Risk acceptance with compensating controls
• Expiration date and re-approval requirement
• Enhanced logging and monitoring for exception accounts

Output artifacts:

• Exception register
• Risk acceptance approvals
• Compensating control evidence (logs, monitoring rules)

---

Required evidence and artifacts to retain (auditor-ready list)

Keep evidence that shows the control exists, is followed, and is enforced:

• Use of External Systems policy/standard (AC-20 scope)
• External Access Terms Matrix (scenario-based)
• External Access Path Register (inventory)
• Trust relationship documentation where applicable (contracts, interconnection agreements, third-party support terms)
• Access request tickets and approvals for external access
• Identity configuration evidence: MFA policies, conditional access rules, federation settings
• Network/control evidence: bastion configuration, VPN/ZTNA policies, segmentation rules
• Logs proving external access is recorded (IdP logs, VPN logs, PAM session logs)
• Periodic access review outputs and remediation evidence
• Exceptions: approvals, expirations, compensating controls ¹

Practical tip: store these artifacts in a single control folder mapped to AC-20 so your assessor does not chase evidence across systems.

---

Common exam/audit questions and hangups

Expect these questions in a FedRAMP assessment package review and during testing:

• “What counts as an external system in your environment, and where is your inventory?”
• “Show me the terms and conditions for contractor/admin access from third-party-managed devices.”
• “How do you ensure only authorized individuals access from external systems?”
• “Prove enforcement: show conditional access/device compliance or show how you restrict access to managed endpoints.”
• “How do you govern federated identity trust with an agency or partner?”
• “Show the last access review for external access groups and what you removed.”
• “How do you revoke access when a contract ends or a device is lost?” ¹

---

Frequent implementation mistakes (and how to avoid them)

Mistake 1: A single generic policy with no scenario detail

Fix: create a terms matrix by access path. Assessors need specificity.

Mistake 2: “Managed devices only” with no way to prove device posture

Fix: tie access to device compliance signals, or route access through VDI/bastion where you control the session.

Mistake 3: Third-party support accounts that never expire

Fix: time-bound grants, separate named accounts, PAM where possible, and a standing monthly review for third-party access.

Mistake 4: Federated SSO set up by engineers without governance

Fix: document the trust, approvals, and claims mapping; restrict which groups can federate into privileged roles.

Mistake 5: Evidence scattered across tickets, chats, and admin consoles

Fix: a single evidence pack per control. Daydream can help teams standardize evidence collection, link tickets to controls, and keep review outputs and exceptions in one audit-ready trail.

---

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source set for AC-20. The practical risk is assessment failure, delayed authorization, or continuous monitoring findings when external access paths are not controlled or evidenced. NIST frames the requirement around trust relationships and terms because external systems are outside your direct control, so weak governance can leave inappropriate access in place with poor defensibility. ¹

---

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

Use phases rather than fixed outcomes. Move from “documented” to “enforced” to “auditable.”

First 30 days (stabilize scope and stop unknown access)

• Build the External Access Path Register.
• Identify high-risk paths (privileged admin access, third-party support tooling, federation).
• Draft the Use of External Systems standard and a first-pass terms matrix.
• Put an approval gate in place for any new external access request (ticket + security approval).

By 60 days (enforce terms with configs)

• Implement conditional access/MFA rules that match the terms matrix.
• Restrict privileged access to approved pathways (PAM, bastion, segmented admin plane).
• Centralize logging for external access events (IdP + remote access + PAM session logs).
• Stand up an exceptions register with expirations and compensating controls.

By 90 days (prove it works, then operationalize)

• Run the first formal access review for external access groups and third-party accounts.
• Close the loop: remove access, document remediation, update the register.
• Package evidence for AC-20 in a single location aligned to FedRAMP documentation expectations. ²
• Automate where feasible: joiner/mover/leaver feeds, periodic access review workflows, evidence capture. Daydream is a good fit if your bottleneck is control evidence, review tracking, and keeping exceptions from going stale.

Frequently Asked Questions

Does “external systems” mean only personal devices?

No. It includes any system outside your authorization boundary that can access the system, including third-party-managed endpoints, partner networks, federated identity systems, and support tooling owned or operated by another organization. ¹

How specific do the “terms and conditions” need to be?

Specific enough that a tester can map each rule to an enforced control and verify it. A short policy plus a scenario-based terms matrix is usually easier to test than a long narrative document.

If we allow federation with an agency IdP, what does AC-20 expect?

Document the trust relationship and define conditions for access (who can federate, which claims/groups map to roles, what MFA/assurance is required, and how you review and revoke). Then retain configuration evidence and review records. ¹

What evidence do assessors usually ask for first?

The inventory of external access paths, the written terms, and proof of enforcement (conditional access/MFA/device compliance or controlled access architecture). They also ask for access requests/approvals and access review outputs. ¹

Can a third party have persistent admin access for support?

AC-20 does not forbid it, but you must define terms consistent with the trust relationship and show that access is authorized, controlled, logged, and reviewed. Many teams time-bound privileged access and use PAM session logging to make this defensible.

How do we keep AC-20 from becoming a documentation-only exercise?

Tie every term to a configuration control and test it like an attacker would: from an unmanaged device, from an unapproved network, and from a non-privileged role. Keep the results with your AC-20 evidence so the control stays auditable over time.

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates