ArcGIS Server can run on infrastructure you manage yourself, a virtual private server (VPS), or a cloud platform. In every case, a secure hosting setup depends on more than the server software: network rules, operating-system maintenance, identity controls, certificates, and the way services are published all matter. A scan is a useful way to find configuration risks, but it is not a guarantee that a system is secure.
This guide explains how to scan ArcGIS Server for security best practices, how to interpret findings, and what to check before and after the scan. It compares common approaches without claiming to test particular hosts or versions. Confirm every recommendation against the documentation for your ArcGIS Enterprise release and your organization’s policies.
What does scanning ArcGIS Server for security best practices mean?
Scanning ArcGIS Server for security best practices means reviewing its configuration and hosting environment for settings that could expose services, weaken access controls, or make maintenance harder. Depending on the tool and scope, a scan may inspect ArcGIS Server settings, reachable network ports, certificates, or operating-system configuration. These are related checks, but they are not interchangeable.
Esri provides ArcGIS Server security guidance and has published a security scan tool for checking ArcGIS Server configuration. The tool’s availability, requirements, and findings can depend on the software release, so start with Esri’s current documentation and the tool’s official distribution page. A configuration scan does not replace vulnerability management, penetration testing, log review, or a review of application code.
How this guide compares scanning approaches
This is a documentation-based comparison, not a benchmark or hands-on review. The criteria are scope, operational effort, fit for different hosting models, and the type of issue each approach can reveal. The named sources are Esri’s ArcGIS Server documentation and security guidance, the Center for Internet Security (CIS) Benchmarks for operating-system hardening, and NIST guidance on security controls and risk management. These sources address different layers; none should be treated as a single complete ArcGIS security checklist.
Esri guidance is the most directly relevant source for ArcGIS-specific configuration. CIS Benchmarks can help teams review the host operating system, but applying a benchmark without testing may disrupt software or required services. NIST publications offer a broader risk-management framework rather than a product-specific scan. Use the sources together, and record which release and benchmark versions informed your decisions.
Before you run a scan
1. Identify the deployment and its owner
Record the ArcGIS Enterprise and ArcGIS Server versions, operating system, hosting provider, and whether the site is standalone or part of a larger deployment. Identify who owns the machine, network perimeter, backups, certificates, and application configuration. In shared hosting, customers often have limited access to server-level controls; ArcGIS Server deployments generally require administrative access and a supported environment. Do not assume a standard shared web-hosting plan can run ArcGIS Server.
For VPS and cloud deployments, distinguish between responsibilities managed by the provider and those retained by your team. A provider may maintain physical infrastructure while you remain responsible for the guest operating system, ArcGIS configuration, firewall rules, and account security. Confirm this division in the service agreement and technical documentation.
2. Choose a safe time and scope
Review the scan documentation before running it, including prerequisites, permissions, supported versions, and whether it makes changes or only reports findings. Schedule scans during an approved maintenance window when practical, particularly on production systems. Back up relevant configuration and establish a rollback plan for any remediation. Avoid running unfamiliar scripts against a live server without approval and a tested recovery path.
Use an authorized account and restrict access to scan output. Reports may reveal hostnames, configuration details, or security weaknesses. Store them in an approved location, share them only with people responsible for remediation, and follow your organization’s retention policy.
3. Check the source and integrity of the tool
Download tools only from Esri or another source your organization has explicitly approved. Verify instructions and compatibility against the relevant Esri documentation; do not rely on a similarly named third-party download. If your security process requires it, validate file integrity using a trusted method and have the script reviewed before execution. A tool’s association with a vendor does not remove the need to understand what it does.
Practical steps to scan and act on findings
Step 1: Establish a baseline
Document the current configuration, including public endpoints, web adaptors or reverse proxies, authentication methods, service exposure, and administrative access paths. Note recent changes and known exceptions. This baseline helps distinguish a new finding from an accepted design choice and makes later comparisons meaningful.
Step 2: Run the ArcGIS-specific configuration check
Follow the instructions for the ArcGIS Server security scan tool that applies to your release. Use the intended permissions and parameters, and preserve the unedited output. Read the tool’s descriptions rather than treating every warning as a confirmed vulnerability. A finding may indicate a configuration that deserves investigation, not proof that an attacker can exploit it.
Step 3: Review the network boundary separately
Check which ports and endpoints are reachable from the internet, partner networks, and internal user networks. Restrict administrative interfaces to trusted management paths, and expose only the services the application requires. Use provider firewall controls, host firewalls, load balancers, or a web application gateway as appropriate to the architecture. Confirm that rules apply to both IPv4 and IPv6 where relevant.
A network port scan can show exposure from the scanner’s location, but it cannot establish that ArcGIS settings are correct. Conversely, an ArcGIS configuration scan may not reveal every upstream firewall or proxy rule. Use authorized network assessment tools and coordinate with the hosting provider before scanning shared infrastructure.
Step 4: Review identity and service access
Check that accounts have only the permissions they need, administrative accounts are controlled, and authentication settings match the organization’s identity design. Review who can publish, administer, and consume services. Remove stale accounts and test access changes with service owners before applying them broadly. Do not weaken authentication simply to make a client integration easier; investigate supported identity options for the deployed version.
Step 5: Verify HTTPS and certificates
Confirm that users reach the service through HTTPS and that certificates are valid, trusted by intended clients, and renewed through a documented process. If a reverse proxy or web adaptor terminates TLS, verify the full path between components according to your security requirements. SSL/TLS setup involves more than obtaining a certificate: incorrect proxy headers, mixed content, or an unprotected backend connection may still create risk.
Step 6: Check the host and maintenance process
Compare operating-system settings with a suitable CIS Benchmark or internal hardening standard, but test changes in a staging environment. Keep ArcGIS Enterprise components and the operating system on supported, patched releases, following Esri’s compatibility and upgrade guidance. Maintain backups and test restoration; a backup that has never been restored is not a reliable recovery plan.
Step 7: Prioritize, remediate, and rescan
For each finding, record its evidence, potential impact, owner, planned action, and any approved exception. Prioritize externally reachable administrative exposure, weak access controls, and unsupported or unpatched components, while considering business impact and the actual deployment context. Apply changes one at a time where feasible, test dependent services, and rescan after remediation. Keep a dated record so future administrators can see what changed and why.
Comparing common hosting and scanning choices
Self-managed VPS or dedicated server
Pros: Greater control over operating-system settings, firewall rules, monitoring, and scan scheduling. This can suit teams with experienced administrators and a clear maintenance process.
Cons: Your team carries more responsibility for patching, backups, access control, and recovery. A low-cost VPS is not automatically secure, and resource limits or unsupported configurations can affect reliability. Review the provider’s supported operating systems and ArcGIS deployment requirements before choosing a plan.
Cloud infrastructure
Pros: Cloud platforms commonly provide configurable network controls, centralized identity options, and infrastructure monitoring. These capabilities can support a layered security design when configured correctly.
Cons: Cloud features add configuration choices and do not secure the application by default. Misconfigured access policies, public endpoints, or unclear responsibility boundaries can undermine the design. Compare providers on documented controls, support, data location requirements, and operational fit—not just advertised performance.
Managed hosting or managed ArcGIS operations
Pros: A qualified provider may handle some maintenance, monitoring, or infrastructure tasks, reducing the operational burden on a small team.
Cons: “Managed” can mean different things. It may not include ArcGIS configuration reviews, application security, or incident response. Get written confirmation of who runs scans, who fixes findings, how quickly issues are addressed, and how you receive reports.
Automated scanning versus manual review
Pros of automation: Repeatable checks can help identify configuration changes and provide a consistent starting point for review.
Cons of automation: A tool sees only what it is designed and permitted to inspect. It can miss issues outside its scope or produce findings that need context. Manual review is better suited to architecture, business exceptions, and service-specific access decisions, but it takes skilled staff and may be less repeatable.
Limitations and common mistakes
- Treating a clean report as a security certification: A scan covers selected checks, not every threat, dependency, or application behavior.
- Applying every recommendation without testing: A setting that is appropriate for one deployment may break a required integration in another. Validate changes against Esri documentation and a test environment.
- Scanning only the ArcGIS application: Host configuration, network exposure, identity systems, DNS, backups, and monitoring also matter.
- Ignoring the version: Guidance and tool behavior may change. Confirm compatibility before using instructions written for another release.
- Leaving findings unowned: A report has little value unless a named team reviews, prioritizes, and closes or formally accepts each issue.
- Assuming provider responsibility is complete: Hosting contracts and managed-service scopes differ. Verify responsibilities rather than inferring them from plan names.
Q&A
Does an ArcGIS Server scan prove that my site is secure?
No. It can identify selected configuration concerns, but security also depends on network design, identity, patching, applications, monitoring, and operational response. Combine scans with a broader review.
Can I scan a production server?
Only if you are authorized and have checked the tool’s documented behavior, requirements, and operational impact. Plan the scan with the system owner, protect the results, and use a maintenance window if appropriate.
Is a VPS safer than shared hosting?
Not by itself. A VPS gives more control, but also places more security work on its administrator. Shared hosting is usually unsuitable for running a full ArcGIS Server deployment, though it may host unrelated parts of a website. Match the service to ArcGIS requirements and your team’s skills.
How often should I scan?
Set a schedule based on your risk, change rate, compliance obligations, and tool guidance. Also consider a scan after significant configuration changes or upgrades. There is no universal interval that is appropriate for every organization.
Conclusion
To scan ArcGIS Server for security best practices, use current Esri guidance for the ArcGIS-specific review, then assess the host, network, identity, TLS, and operational controls as separate layers. Treat results as evidence for investigation, not a pass-or-fail verdict. The strongest process pairs authorized, repeatable checks with tested remediation, clear ownership, and documented exceptions. Hosting choice matters, but day-to-day configuration and maintenance determine whether the available controls are actually effective.
Informational disclaimer: This guide is not a security audit or a substitute for advice from a qualified ArcGIS administrator or security professional. Confirm changes against your supported deployment and organizational requirements before applying them.