A remote access policy for developers should cover which devices may reach which systems, how people sign in, how long sessions last, where secrets live, what happens on personal phones, and what to do when a device is lost. Keep it short enough to read, and tie each rule to a system you can check.
Start from NIST's frame
NIST SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security, was published in July 2016. Its abstract says every component of these technologies, including organization-issued and personal devices, should be protected against threats found through threat modeling. It covers several types of remote access solutions, recommends ways to secure telework, remote access and BYOD, and gives guidance on writing related policies. It is older than some current practice, so use it as a structure and check newer guidance such as NIST SP 800-124 Rev. 2 (May 2023) for mobile devices.
The outline
- Purpose and scope. Who and what the policy covers: employees, contractors, which systems.
- Approved devices. Company managed laptops, and whether personal phones or laptops are allowed, and for what.
- Device baseline. Screen lock, updates, disk encryption, remote lock and erase.
- Sign-in. Phishing resistant methods for source control, package publishing, cloud and CI. A fallback path that is not SMS where possible. See push approval fatigue.
- Sessions. Idle and absolute timeouts, and reauthentication for sensitive actions. See how long a remote session should last.
- Networks. What is acceptable on public networks. Encrypted connections only. Whether a VPN or an identity aware proxy is required.
- Secrets. Where they live, how they are issued, and rules against storing them in notes, chat or screenshots.
- Remote environments. Which cloud dev environments are approved, who can create them, port visibility rules. See port forwarding in cloud dev environments.
- AI tools and agents. Which are approved and what they may do. See which agent actions should ask first.
- Lost or stolen devices. Who to tell, in what time, and what gets revoked. See the lost phone playbook.
- Exceptions. How to ask, who approves, and when it expires.
- Enforcement and review. How you check it, and when the policy is reviewed.
Write rules you can check
Compare two lines.
- Weak: "Devices must be secure."
- Better: "Devices that access source control must have a screen lock, automatic updates on, and be enrolled in device management or marked as exempt by the security lead."
The second one can be audited. If you plan to use the policy as evidence for an audit, each rule should map to a setting, a report or a record.
The personal phone question
Decide plainly. Options:
- No access from personal phones. Simple, but people will find ways around it.
- Read only access to alerts and chat, with a screen lock and updates required. A middle path.
- Full access through a managed profile that separates work data. More setup, more control.
Our BYOD decision guide goes through the tradeoffs.
Keep it alive
- Keep it to two or three pages, with a one page summary.
- Review every year and after any incident.
- Test the lost device steps once a year.
- Tell new hires on day one, and show them how to set up their devices.
Quick check
Do we need a separate policy for remote work?
Not necessarily. You can fold it into an acceptable use or access control policy. What matters is that the rules exist, are specific and can be checked.
Is NIST SP 800-46 still current?
Revision 2 is from July 2016. Use it for structure, and add newer guidance on mobile devices, sign-in and cloud services. Check NIST's site for any later revision.
Sources
Last reviewed: 19 October 2026.
