Accountability usually sits with security, IT, and business leaders together because credential and device risk affects both access governance and user productivity. Security teams define control requirements, IT implements device and access management, and business leaders approve the risk posture for BYOD and remote work. Clear ownership is essential for compliance, support efficiency, and incident response.
Why This Matters for Security Teams
Remote and flexible work turns credential and device security into a shared accountability problem, but shared does not mean vague. Security teams need to define the control baseline, IT needs to operate enrollment, patching, and access enforcement, and business leaders need to accept the productivity and risk tradeoffs behind BYOD, contractor access, and off-network work. The practical issue is that compromise rarely starts as a device problem alone; it often begins with credential exposure and then becomes a device trust problem.
NHI Management Group research on secret sprawl shows why this matters: exposed credentials and overbroad access are still common paths into production systems, as highlighted in the Guide to the Secret Sprawl Challenge. NIST guidance on identity assurance also reinforces that authentication strength, device state, and session context all matter together, not separately, as reflected in NIST SP 800-63 Digital Identity Guidelines. In practice, many security teams encounter ownership gaps only after a lost laptop, phishing event, or unmanaged home device has already turned into an access incident.
How Accountability Is Assigned in Practice
The cleanest operating model is to separate policy ownership from control operation. Security owns the risk requirements, IT owns the technical implementation, and business owners approve exceptions where remote work needs to continue despite higher exposure. That usually includes decisions about MFA strength, device posture checks, local admin rights, secrets storage, conditional access, and when a device must be isolated or blocked.
For credentials, the accountable function should ensure that access is tied to strong identity assurance, short-lived sessions where possible, and rapid revocation when a device or user context changes. For devices, the accountable function should require encryption, MDM or endpoint management coverage, patch compliance, and logging. The NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary many organisations map to these duties, while the OWASP Non-Human Identity Top 10 is useful where remote workflows also depend on service accounts, tokens, and automation identities.
A practical accountability model often looks like this:
- Security defines minimum control requirements and exceptions policy.
- IT implements device enrollment, posture enforcement, and credential lifecycle tooling.
- Business leadership accepts residual risk for flexible work scenarios.
- Audit or risk functions verify that ownership is documented and tested.
This model works best when the organisation can enforce device management and identity policy across all endpoints, because it breaks down when contractors, personal devices, or unmanaged mobile endpoints access sensitive systems without reliable posture telemetry.
Common Variations and Edge Cases
Tighter credential and device controls often increase friction for employees, contractors, and support teams, so organisations have to balance security with the operational reality of flexible work. That tradeoff is especially visible in BYOD, executive travel, and bring-your-own-access scenarios where full device control is either impractical or politically difficult.
Current guidance suggests that exception handling should be explicit rather than informal. If a personal device is allowed, the organisation should document what is monitored, what is not, and what data the device may access. If a contractor needs access, the account owner should still be clear even when sponsorship sits with procurement or a third-party manager. NHI Management Group’s Ultimate Guide to NHIs and 230M AWS environment compromise both show how fast weak secret handling can turn into broad exposure once access is detached from governance.
There is no universal standard for this yet, but best practice is evolving toward shared accountability with named control owners, time-bound exceptions, and regular review of both endpoint posture and privileged access. That is particularly important in hybrid organisations where the same user may switch between managed laptop, mobile device, and home network within the same day.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity and credential governance depend on clear access ownership. |
| NIST SP 800-63 | IAL/AAL/FAL | Remote work security hinges on identity assurance and authentication strength. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Remote work often exposes secrets and tokens across endpoints and sessions. |
| NIST AI RMF | GOVERN | Shared accountability needs formal governance for identity and device risk decisions. |
| NIST Zero Trust (SP 800-207) | PR.AC-5 | Zero trust ties access decisions to device state and context, not network location. |
Assign named owners for access policy, then review remote access permissions against least privilege.
Related resources from NHI Mgmt Group
- Why does identity security matter when organisations need to support remote work and distributed teams?
- Who should own identity security decisions when cloud, remote work, and automation are expanding together?
- How should organisations implement identity and access governance in cloud and remote work environments?
- What do organisations get wrong when they try to secure flexible work with legacy controls?
