What do organisations get wrong when they try to secure flexible work with legacy controls?

Why This Matters for Security Teams

Legacy controls were built for a world where access was mostly predictable: fixed offices, managed endpoints, and network perimeters that could be trusted more often than not. Flexible work breaks that model because users move across home networks, SaaS apps, collaboration tools, and personal devices while still needing access to sensitive data. The problem is not just location. It is the mismatch between static rules and a dynamic operating environment. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a controls issue, but in practice it is an identity and context problem first. When access decisions depend on IP ranges, VPN presence, or broad group membership, teams miss the real question: should this request be allowed right now, from this device, for this app, under these conditions? NHIMG research shows how broad the exposure can be, with only 5.7% of organisations having full visibility into their service accounts, which is a useful warning sign for human access too. In practice, many security teams encounter the failure only after a user logs in successfully from an untrusted context and data has already moved out of the controlled environment.

Flexible work also exposes where legacy controls over-rely on the network boundary instead of the transaction itself. That makes it easier for approved users to access the wrong resources, and harder to distinguish legitimate work from risky behaviour. The result is usually not a dramatic bypass. It is silent over-permissioning, weak device assurance, and access paths that stay open long after they should have closed. For deeper NHI governance parallels, see Ultimate Guide to NHIs — Standards and the control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls.

How It Works in Practice

Modern flexible-work controls shift from perimeter trust to identity-centred, risk-aware decisions. That means the access broker evaluates the request at runtime using signals such as user identity, device posture, app sensitivity, session history, location anomalies, and the data involved. Current guidance suggests treating the network as one signal among many, not the primary control. For organisations dealing with sensitive systems, this usually means combining conditional access, least privilege, and continuous verification rather than relying on a VPN or a flat internal network.

• Require strong authentication, but do not stop there. Pair it with device compliance and session risk scoring.
• Use short-lived tokens and re-evaluate access when context changes, instead of trusting a login for the whole day.
• Separate approved business apps from unapproved apps, and apply different policies to each.
• Log and review access decisions as part of governance, not only as an incident response activity.

In NHI terms, this is the same logic that underpins stronger lifecycle control: identity plus context beats static allowlists. The broader NHI governance model described in the Ultimate Guide to NHIs — Standards shows why visibility, rotation, and offboarding matter when credentials are persistent. For flexible work, the analogue is that access should be bounded by time, device trust, and task context, not by where the user happens to be. These controls tend to break down in BYOD-heavy environments with inconsistent device telemetry because policy engines cannot reliably distinguish managed from unmanaged risk.

Common Variations and Edge Cases

Tighter access control often increases friction, requiring organisations to balance user convenience against the need to reduce exposure. That tradeoff is especially visible in hybrid and contractor-heavy environments, where rigid controls can slow legitimate work if device onboarding, policy exceptions, or app classification are not well designed. Best practice is evolving, but there is no universal standard for this yet: some organisations allow limited access from unmanaged devices through browser isolation, while others block all high-risk workflows until device trust is established.

There are also edge cases where legacy controls fail in different ways. Shared devices in frontline settings can make individual session attribution difficult. Temporary staff can create role sprawl if access packages are too broad. High-risk SaaS integrations may look like normal user access but actually behave like privileged automation, which means they need different governance. That is why flexible-work security should not stop at “remote access protection.” It should classify the kind of request, the sensitivity of the app, and the confidence in the endpoint before granting anything beyond the minimum necessary. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful, but it must be applied with modern context-aware enforcement rather than inherited perimeter assumptions.

Related resources from NHI Mgmt Group

• What do security teams get wrong when they try to launch identity governance too quickly?
• What do organisations get wrong when they secure AI only at the model layer?
• What do organisations get wrong when they treat biometric authentication as stronger than all other controls?
• What do organisations get wrong about governing apps outside SSO?