Shared administrative accounts are one of the most common findings we encounter in ArcGIS security reviews. They are also one of the most frequently deferred, even though they are often among the simpler security issues to address.
Why does it matter?
Shared administrative accounts weaken attribution, accountability and the principle of least privilege because it becomes difficult to determine who performed a particular action and when multiple people use the same privileged account.
This is why Maturity Level 2 expects dedicated privileged accounts, separation of administrative activity from day-to-day user activity, regular validation of privileges and clear auditability. The objective is straightforward: administrative access should be traceable to an identifiable individual and privileges should be appropriate to the role being performed. These expectations appear consistently in security assessments because they support both accountability and assurance.
So why is it still there?
In our experience, the issue is rarely a lack of awareness. Most organisations understand the risks associated with shared administrative accounts and why the finding appears in a review.
The challenge is usually that the account has become embedded in the way the environment operates. It may support an integration, an automated workflow or a business-critical process that has been running reliably for years. Addressing the finding means making changes to something that currently works, which is why other priorities often take precedence.
That hesitation is understandable. Most ArcGIS environments accumulate a few of these accounts over time, and the finding can persist through multiple reviews because resolving it requires careful consideration of the dependencies around it, not because anyone disputes the recommendation.
What does closing it actually involve?
Closing the finding usually starts with understanding where the account is being used and what depends on it.
The specific approach will vary between environments but from there, organisations can identify the integrations, services and processes that need to be considered before any changes are made. The goal is not to replace everything at once, but to understand the dependencies and address them in a controlled and deliberate way.
Where should you start?
If this finding sounds familiar, that’s because it reflects a broader pattern we see across many ArcGIS environments: well-understood issues often remain on the backlog because addressing them means disturbing something that already works, a challenge we explored in Stop parking it: meeting the Essential Eight with ArcGIS may be more achievable than you think.
Onneer specialises in the secure deployment and configuration of ArcGIS environments. We help organisations understand how security requirements apply in the context of ArcGIS, complementing broader cyber security assessment activities rather than replacing them. If you’re trying to decide where to focus next, we’re happy to talk through what we’re seeing across ArcGIS environments.
