Join our Newsletter — 33% off our NHI Course

What should organisations do about non-domain joined computers that cannot rely on standard Group Policy?

Use an endpoint control approach that can enforce browser settings outside the domain, especially for contractors and remote workers. Those devices still need the same credential-storage restrictions, but the control plane must reach them through a local agent or equivalent management method. Otherwise, unmanaged endpoints become the easiest place for browser-stored passwords to persist.

How should unmanaged endpoints be handled when Group Policy is unavailable?

When a computer cannot join the domain, the practical answer is to treat it as an endpoint management problem, not a directory policy problem. You still need a way to push browser and credential-storage controls to that device, but the enforcement path shifts to local management tooling, an endpoint agent, or another control plane that reaches outside the domain.

The core design question is whether the device can receive and keep policy reliably. If it cannot, then any control that depends on Group Policy will be inconsistent by definition. For contractors, remote staff, and other non-domain managed users, the policy has to travel with the endpoint, not with the network location.

That usually means separating the setting itself from the domain dependency. Browser hardening, password storage restrictions, and similar controls should be implemented in a way that survives off-network use and does not rely on constant LAN presence. CSA Cloud Controls Matrix is useful here as a control-oriented reference because it frames endpoint, identity, and governance expectations as managed security outcomes rather than as domain-specific mechanics.

What enforcement models work outside a domain?

The most common approach is a locally enforced endpoint agent that can apply configuration directly on the device. That can be a unified endpoint management tool, a hardened browser management client, or another local control method that writes the setting where the browser actually reads it. The important part is not the brand of tool, but that the control remains active even when the machine is off the corporate network.

For some environments, browser policy can also be delivered through cloud-based device management, provided the device remains enrolled and the policy channel is trusted. In practice, that is often the right pattern for hybrid work because it preserves central policy while avoiding the domain join requirement. A general controls reference such as NIST Cybersecurity Framework 2.0 supports this kind of thinking because it emphasises govern, protect, and identify functions across different operating models.

If the organisation cannot guarantee any management channel, the device should be treated as unable to meet baseline control requirements for sensitive access. At that point, the issue is not just convenience, it is whether the endpoint can be trusted to handle stored credentials at all. That is why browser policy and access policy need to be aligned, not handled as separate problems.

Why browser-stored credentials become the real exposure

When unmanaged endpoints are allowed to save passwords, the security issue is persistence. The browser becomes a local repository for reusable credentials, and those credentials may survive long after the user leaves, the contractor engagement ends, or the machine changes hands. In that situation, the endpoint is no longer just a device, it is a standing access path.

That exposure is especially serious when the same device is used for multiple accounts, or when the browser profile syncs across devices. A stolen or shared laptop can then expose not only the local account but also downstream systems reached through saved credentials. The relevant control mindset is least privilege plus credential minimisation, with a bias toward preventing storage rather than trying to detect misuse after the fact.

NIST Cybersecurity Framework 2.0 is again helpful as a governance lens, because the issue is not only technical hardening but also whether the organisation has defined and enforced acceptable access paths for unmanaged endpoints.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CSA Cloud Controls Matrix, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
CSA Cloud Controls Matrix IAM — Identity & Access Management Unmanaged endpoints still need enforceable access and endpoint control.
Recommendation — Apply IAM controls to centralise device and credential policy enforcement.
NIST CSF 2.0 PR.AA-05 — Managed Authentication Factors Browser-stored credentials on unmanaged endpoints affect how auth is controlled.
PR.PS-03 — Least Functionality Restricting browser password persistence reduces unnecessary endpoint capability.
Recommendation — Enforce managed authentication and block uncontrolled credential storage on endpoints. Remove or disable browser password storage on unmanaged devices.
ISO/IEC 27001:2022 A.8.1 — User endpoint devices Non-domain computers require endpoint-specific security management.
Recommendation — Define and enforce security requirements for unmanaged endpoint devices.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Saved browser passwords are authenticator material that must be managed.
Recommendation — Rotate and restrict stored authenticators that could persist on endpoints.

Practitioner Guidance

What to prioritise: Decide first whether the non-domain device is permitted to store credentials at all. If the answer is no, the control must be enforced at the browser or endpoint layer, not as a user instruction.

What to verify: Confirm that the management method still applies policy when the device is off-network, and that it can override local browser defaults consistently across the contractor and remote-worker population.

Common mistake: Treating “not domain joined” as “not manageable.” In practice, that usually leaves the organisation with the weakest possible control surface: unmanaged endpoints holding reusable credentials.

Practitioner takeaway: For endpoints outside the domain, the real decision is whether the organisation can impose durable control on the device itself, if it cannot, browser password storage should be assumed unsafe for any sensitive access.