Amazon WorkSpaces moves the desktop into AWS, but a stolen password, an unmanaged laptop or an open clipboard still lets data walk out of it. WorkSpaces Personal security rests on four decisions that are easy to leave at their defaults: which directory authenticates users, whether a second factor or certificate is required, which devices and networks may connect, and what may cross between the virtual desktop and the user's machine. The defaults are permissive: the default IP access control group allows access from anywhere, users are local administrators, and DCV clipboard redirection is two-way. This guide covers directory types, MFA, SAML and certificate-based authentication, trusted devices, IP access control groups, redirection policies, encryption, administrative roles, logging and a hardening baseline. It is written for end-user computing and security engineers running WorkSpaces Personal. Cross-product virtual desktop risk is covered in the Virtual Desktop (VDI) and DaaS Security Guide; this page stays on WorkSpaces.
This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.
Key takeaways
- The directory is the front door. AD Connector, AWS Managed Microsoft AD and Simple AD authenticate users with directory passwords; add RADIUS MFA or SAML 2.0 federation so a password alone is never enough.
- Close the SAML bypass. The setting that lets clients without SAML 2.0 support log in with directory credentials is meant for upgrades only; leave it off in steady state.
- Change the network default. Each directory's default IP access control group allows any source; associating a custom group replaces it, but it controls streaming only, not API actions such as reboot or rebuild.
- Trust devices by certificate. Trusted devices blocks Windows, macOS and Android clients that cannot present a certificate chaining to one of up to two imported roots; block the client types you do not use.
- Restrict what crosses the boundary. Use Group Policy to limit clipboard direction, printing, session storage and USB, and remove local administrator rights for new and rebuilt WorkSpaces.
How identity and access work in WorkSpaces
Directory types
| Directory | What it is | Authentication | Notes from AWS documentation |
|---|---|---|---|
| AD Connector | Proxy to your existing on-premises Active Directory | On-premises AD credentials; RADIUS MFA | Users reach on-premises resources; the connector's service account is a privileged non-human identity |
| AWS Managed Microsoft AD | Microsoft AD hosted by AWS | Directory credentials; MFA; trusts to on-premises domains | With multi-Region replication, only the primary Region directory can be registered |
| Simple AD | Samba 4 based, AD compatible, hosted by AWS | Directory credentials | Suits small, self-contained deployments |
| Microsoft Entra ID (through IAM Identity Center) | Entra native join, Intune enrolment through Windows Autopilot user-driven mode | Entra ID | Windows 10 and 11 BYOL WorkSpaces only |
| Custom (through IAM Identity Center) | Identity provider of your choice, with your own device management | Your IdP | Windows 10 and 11 BYOL WorkSpaces only |
Directory-based controls such as trusted devices and the local administrator setting apply only to directories managed through AWS Directory Service (Simple AD, AD Connector and AWS Managed Microsoft AD). Shared directories are not supported. Directory hardening itself is covered in the AWS Managed Microsoft AD Security guide.
Strengthening sign-in
| Method | How it works | Key settings | Choose it when |
|---|---|---|---|
| RADIUS MFA (AD Connector, Managed AD) | Directory password plus a code checked by your RADIUS server | Server IPs or load balancer, port (default UDP 1812), shared secret, protocol, timeout 1 to 50 seconds, retries 0 to 10; active only when RADIUS status is Enabled | You already run RADIUS-based MFA and want minimal change |
| SAML 2.0 federation | User authenticates at your IdP, which asserts an IAM role allowed workspaces:Stream on the directory where workspaces:userId equals ${saml:sub} | IAM SAML provider; role trust with SAML:sub_type = persistent and sts:TagSession; relay state URL with the registration code | You want IdP policies (MFA, conditional access) in front of every session |
| Certificate-based authentication (with SAML) | After SAML sign-in, WorkSpaces logs the user on to AD with a virtual smart card, removing the domain password prompt | AWS Private CA tagged euc-private-ca, RSA 2048, CA published to NTAuth; userPrincipalName and ObjectSid in the assertion | You want passwordless desktop logon; enforce MFA at the IdP, because CBA does not prompt for it |
- SAML bypass setting: Allow clients that do not support SAML 2.0 to login lets older clients skip the IdP and use directory credentials. AWS describes it as a way to keep access during client upgrades; turn it off once clients are current.
- Strong mapping: CBA authentication fails if
ObjectSiddoes not match the SID of the user named in the SAML subject. AWS notes that, per Microsoft KB5014754,ObjectSidbecame mandatory after 10 September 2025. - Short-lived certificates: WorkSpaces issues a new end-user certificate every 24 hours, so there is nothing to revoke, but the CRL endpoint of the CA must be reachable from desktops and domain controllers. Do not use a short-lived mode CA to issue domain controller certificates.
- CBA support: Windows WorkSpaces on DCV bundles with current Web Access, Windows client 5.5.0 or later, or macOS client 5.6.0 or later.
- MFA rollout warning: users cannot log in while MFA is being set up, so schedule the change. See the MFA Guide.
Admin roles and privileged access
| Identity | Purpose | Control |
|---|---|---|
workspaces_DefaultRole | Service role trusted by workspaces.amazonaws.com, with AmazonWorkSpacesServiceAccess, AmazonWorkSpacesSelfServiceAccess and AmazonWorkSpacesPoolServiceAccess | Required to register a directory by API; AWS warns not to attach a permissions boundary |
AmazonWorkSpacesPCAAccess | Service role for certificate-based authentication, trusted by prod.euc.ecm.amazonaws.com | Created when CBA is enabled; audit its use through Private CA events |
| WorkSpaces administrators | Create, rebuild, restore and terminate WorkSpaces; change directory settings | Resource-level permissions on directory, WorkSpace, bundle, image and IP group ARNs where supported |
| Directory administrators | Manage users, groups and Group Policy in the directory | Separate from AWS console roles; tiered admin accounts |
| Local administrators on each WorkSpace | Install software, change settings | On by default; turn off the local administrator setting |
- Scope
iam:PassRole: AWS's example uses theiam:PassedToServicecondition set toworkspaces.amazonaws.com. Some actions, such asDescribeWorkspaces,CreateIpGroupandModifyAccount, do not support resource-level permissions and need"Resource": "*", so put guardrails around who holds them. - Console needs directory rights: console users need
ds:*on all resources, which is broad. Prefer automation or a narrowly assigned operator role for routine work. - Local administrator setting: applies to new WorkSpaces and to WorkSpaces you rebuild; existing desktops keep their current state until rebuilt. Plan a rebuild wave after turning it off.
- Restore and rebuild are sensitive: anyone who can rebuild a WorkSpace can disrupt a user, and these API actions are not limited by IP access control groups.
See the AWS IAM Policies and Roles Guide and the AWS IAM Identity Center Guide.
Integrations, API tokens and service accounts
- AD Connector service account: AD Connector uses a directory service account to join WorkSpaces and look up users. Give it only the delegated rights AWS documents for joining computers in the chosen OU, rotate its password and update it in WorkSpaces when it changes.
- RADIUS shared secret: a static secret shared between the directory and your RADIUS servers; store it in a vault, restrict UDP 1812 to the directory's addresses and rotate it on staff changes.
- SAML signing and IAM roles: the IAM SAML provider trusts your IdP's metadata; the federation role is the real authorisation point, so keep its policy to
workspaces:Streamon the specific directory with theworkspaces:userIdcondition. - Private CA sharing: a central account can share its CA through AWS RAM with the
AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthoritypermission. A shared CA ARN must be associated with the CLI. Guard that CA closely, because it can issue smart card logon certificates. See the AWS Certificate Manager and Private CA Guide. - Device certificates: the trusted devices feature relies on certificates issued by your own PKI and deployed by MDM or configuration management. Revocation through CRL or OCSP is not supported, so removing a lost device means changing roots or relying on other controls.
Logging and detection
| Signal | Source | Use |
|---|---|---|
WorkSpaces Access events (source aws.workspaces), with clientIpAddress, clientPlatform, clientVersion, workspaceId | Amazon EventBridge | Successful logins by location and client; alert on unexpected countries, platforms or old client versions. Events are best effort. |
| Directory, IP group, bundle and WorkSpace changes | AWS CloudTrail (WorkSpaces API) | Detect disassociated IP groups, re-enabled local admin, MFA or SAML changes |
GetCertificate and IssueCertificate from acm-pca.amazonaws.com under EcmAssumeRoleSession | CloudTrail (AWS Private CA) | One per CBA request; baseline and investigate spikes |
| KMS use with encryption context including the user's AD SID and directory ID | CloudTrail (KMS) | Tie volume decrypts to users |
| Windows security events in the desktop and on domain controllers | Your EDR and SIEM | Failed logons, privilege use, smart card logon |
Metrics: share of directories with MFA or SAML enforced and the bypass setting off (target 100 percent); directories still using the default allow-any IP group (target zero); share of WorkSpaces without local administrator rights; share of logins from trusted devices; WorkSpaces without volume encryption (target zero); logins from client versions below your minimum. See the AWS CloudTrail Guide.
Hardening baseline
Network and device access
- IP access control groups: up to 30 rules per group, 35 groups per directory and 140 groups per Region per account. Associating a custom group removes the default allow-anywhere group; a group with no rules blocks everything. Add the public IPs of NAT gateways or VPNs, which must be static. Changes apply to new sessions, but removing a rule disconnects an active user it allowed. Do not associate a group with a directory that uses a VPC endpoint for streaming.
- Trusted devices: in Directories > Access control options, set each client type to Trusted Devices, Allow all or Deny all. Supported for Windows, macOS and Android (including Chrome OS); Linux and iPad clients, and third-party PCoIP and RDP clients, are not, so deny those types if you rely on device trust. Device certificates need a Common Name, Digital Signature key usage and Client Authentication extended key usage, with a chain length of four or less.
Redirection and data controls (Group Policy)
| Control | DCV policy and default | PCoIP policy and default | Hardened setting |
|---|---|---|---|
| Clipboard | Configure clipboard redirection; two-way | Configure clipboard redirection; both directions | Paste Only (client to desktop) or disabled for sensitive data |
| Printing | Configure remote printing; basic enabled | Configure remote printing; basic enabled | Disabled where printing is not a business need |
| File transfer | Configure session storage; disabled | Not applicable | Keep disabled, or Upload Only |
| USB | Enable/disable USB; disabled | USB rules; only YubiKey U2F officially supported | Disabled except approved security keys |
| Idle sessions | Configure Idle Disconnect Timeout; disabled (60 minutes when enabled) | Session automatic reconnection, 20 minutes | Enable idle disconnect; disconnect on screen lock |
| Streaming encryption | Configure security settings; TLS 1.2 cipher list | Configure PCoIP Security Settings; 128-bit default | PCoIP: AES-256-GCM only |
| Screen capture | Configure Screen Capture Protection | Not applicable | Enable for regulated data |
Most policy changes take effect after a Group Policy refresh and session restart. AWS warns not to use the Windows idle time limit for Remote Desktop Services sessions with DCV, because it disconnects active sessions, and not to restrict access to drives C or D.
Encryption
Encrypt root and user volumes at launch with a symmetric KMS key: existing WorkSpaces cannot be encrypted, encryption cannot be removed, and a disabled key makes the WorkSpace unusable on reboot or rebuild. BitLocker is not supported. When rotating a customer managed key manually, keep the old key enabled. See the AWS KMS Security Guide.
Rollout order
- Inventory directories, IP groups, client types in use (from
WorkSpaces Accessevents), local admin state and encryption state. - Enable MFA or SAML on a pilot directory with the bypass setting on; move users; then turn the bypass off.
- Create a custom IP group with office, VPN and NAT addresses; associate it with the pilot directory and watch for disconnections.
- Deploy device certificates by MDM, set pilot client types to Trusted Devices, then deny unsupported client types.
- Apply redirection policies to a pilot OU, collect user feedback, then extend.
- Turn off local admin and rebuild in waves; replace unencrypted WorkSpaces with encrypted ones.
- Rollback: each step is a directory or GPO setting that can be reverted; keep the previous IP group and GPO versions documented.
Small versus large: a small team can use Simple AD or Managed AD with RADIUS MFA, one custom IP group and default GPO hardening. Large estates usually federate with SAML and CBA, use AD Connector or Managed AD trusts, device trust through MDM and per-OU redirection policies for different data classes.
Common misconfigurations
- Default IP group left in place: any internet address can attempt to stream with stolen credentials.
- SAML enabled with the bypass left on: attackers simply use an older client and the directory password.
- Trusted devices enabled for Windows but Linux or web clients allowed: the device check is sidestepped through an unsupported client type.
- Two-way clipboard and printing on desktops holding regulated data: the virtual desktop no longer contains the data.
- Users left as local administrators: malware and unapproved tools install freely, and the setting only changes on rebuild.
- Unencrypted volumes: encryption cannot be added later, so an estate launched without it must be rebuilt.
Framework mapping
| Control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique addressed |
|---|---|---|---|
| MFA, SAML, certificate-based authentication | IA-2, IA-5 | PR.AA-05 | T1078 Valid Accounts, T1110 Brute Force |
| IP access control groups, trusted devices | AC-17, SC-7 | DE.CM-01 | T1078 Valid Accounts |
| Local admin removal, admin role scoping | AC-6, AC-2 | PR.AA-05 | T1098 Account Manipulation |
| Volume encryption, streaming encryption | SC-28, SC-8 | PR.DS-02 | T1557 Adversary-in-the-Middle |
| Access events and CloudTrail | AU-2, AU-6 | DE.CM-01 | T1078 Valid Accounts |
Practitioner checklist
- Every directory enforces MFA or SAML 2.0, and the non-SAML client bypass is off.
- CBA, where used, has
ObjectSidin assertions and MFA enforced at the IdP. - A custom IP access control group with static office, VPN and NAT addresses on every directory.
- Trusted devices set for supported clients, unsupported client types denied.
- Clipboard, printing, session storage and USB restricted by GPO per data class; idle disconnect on.
- Local administrator setting off and WorkSpaces rebuilt.
- Root and user volumes encrypted with a managed symmetric KMS key.
iam:PassRolescoped withiam:PassedToService; WorkSpaces admin rights separate from directory admin rights.- EventBridge rule on
WorkSpaces Accessevents feeding the SIEM, with alerts on unexpected locations and clients.
Standards and references
- AWS: Manage directories for WorkSpaces Personal
- AWS: Multi-factor authentication (AD Connector) for WorkSpaces Personal
- AWS: Set up SAML 2.0 for WorkSpaces Personal
- AWS: Certificate-based authentication and WorkSpaces Personal
- AWS: Restrict WorkSpaces Personal access to trusted devices
- AWS: IP access control groups for WorkSpaces Personal
- AWS: Manage your Windows WorkSpaces in WorkSpaces Personal (Group Policy)
- AWS: Encrypted WorkSpaces in WorkSpaces Personal
Related NHI Mgmt Group resources: Virtual Desktop (VDI) and DaaS Security Guide, AWS Managed Microsoft AD Security, AWS Security Guide, Remote Desktop (RDP) Security Guide.