The main friction is not the technology itself, but ownership, budget, and communication across departments that often operate separately. Physical security owns the room, IT owns the servers, and converged access forces those responsibilities to overlap. Without a clear operating model, teams can stall on accountability, reporting, and who is responsible for the integrated environment.
Why converged access work stalls before the technology is even tested
Converged access initiatives usually fail at the operating model stage, not the hardware or software stage. Physical security and IT are being asked to share a control surface that used to be separated by clear boundaries, so the hard part becomes who owns policy, funding, exception handling, and escalation when the same access path touches both a door and a system.
That makes alignment less about selecting a platform and more about agreeing on decision rights. If the organisation cannot define who approves access, who administers it, and who answers when the control fails, the initiative will feel stalled even when both teams support the idea in principle.
Why ownership, budget, and reporting become the real blockers
Physical teams tend to think in terms of facilities, badges, and site risk, while IT teams think in terms of accounts, endpoints, and service continuity. Converged access collapses those categories into one process, which means existing budgets, KPIs, and audit trails no longer map cleanly to a single department. The result is friction over cost allocation, reporting lines, and whose metrics define success.
That friction usually shows up in one of three places: funding for the shared platform, responsibility for lifecycle changes, and accountability for exceptions. For example, a lockout event may start as a physical issue but quickly become an IT support problem if the same identity is used across systems. ISO/IEC 27001:2022 Information Security Management is a useful reference point here because it frames access control, privileged access, and authentication as governance-backed controls rather than siloed team tasks.
Common failure happens when each team assumes the other will absorb the integration burden. That leaves reporting gaps, duplicated approvals, and “temporary” exceptions that become permanent because no one owns the shared process end to end.
What a workable converged access model has to settle early
A converged programme needs explicit answers on governance before rollout: which team owns policy, which team runs operations, which team handles incident response, and which team can approve exceptions. It also needs one record of truth for access decisions, otherwise the organisation ends up with parallel workflows that undermine the very control it was trying to unify.
The operating model should define lifecycle points clearly, especially joiner, mover, leaver, and emergency access events. If the process cannot state when access is granted, changed, revoked, and reviewed, the integration will drift into ambiguity and the project will lose trust from both sides. CIS Controls v8 is relevant because it anchors account management, access control, and audit logging as practical safeguards that depend on ownership clarity.
Good convergence also respects the fact that physical and logical access are different risk environments even when they share a platform. The strongest programmes do not force identical workflows everywhere, they standardise the governance layer while allowing different enforcement rules where the environment demands it.
Risk and Threat Considerations
Converged access becomes risky when the overlap between physical and IT access is treated as an administrative convenience instead of a control dependency. Weak ownership can create orphaned access, slow revocation, and inconsistent approval paths, all of which enlarge the blast radius if a badge, account, or shared credential is misused.
Failure mechanism: The initiative fails when no single operating model governs provisioning, review, and removal across both domains, so exceptions accumulate and attackers or insiders can exploit stale or overbroad access paths.
Impact: Access sprawl can lead to unauthorized entry, delayed incident response, failed audits, and uncertainty about which team must contain the problem when access is abused or compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared access governance hinges on defined access control ownership and policy. |
| A.8.2 — Privileged access rights | Converged environments often fail on who governs elevated access across teams. | |
| A.8.5 — Secure authentication | Converged access depends on trusted authentication across physical and IT systems. | |
| Recommendation — Define one access-control owner for the converged process and document approval, review, and exception handling. Assign privileged-access governance to a named owner and require time-bounded exceptions. Standardise authentication assurance so both physical and IT access decisions rely on the same trust level. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is fundamentally about who manages shared access and lifecycle responsibility. |
| CIS-5 — Account Management | Converged access creates lifecycle and accountability issues for shared identities and accounts. | |
| Recommendation — Centralise access control management and enforce clear ownership for provisioning and revocation. Maintain a single account lifecycle process with documented ownership and periodic review. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Account lifecycle governance is central when physical and IT access are unified. |
| AC-6 — Least Privilege | Converged access often fails when teams grant broad access to avoid coordination overhead. | |
| AU-2 — Event Logging | Shared access requires auditable evidence across both domains when ownership is split. | |
| Recommendation — Implement one account lifecycle workflow with approval, review, and timely deactivation steps. Limit converged access to the minimum permissions needed and review exceptions regularly. Log access events consistently so both teams can investigate and reconcile control actions. | ||
Practitioner Guidance
What to prioritise: Start by defining decision rights, not tooling. If the organisations cannot agree on who approves access, who owns lifecycle changes, and who carries the exception log, the platform discussion is premature.
What to verify: Test the process with a real scenario, such as a terminated employee, a role change, or an emergency access request. The control only works if both teams can show how the access is revoked, who confirms completion, and where the evidence is retained.
Practitioner takeaway: Converged access succeeds when governance is designed as a shared operating model with clear ownership and evidence, not as a technology purchase that assumes collaboration will happen later.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
