Sage CRM Security Hardening Checklist

A Practical Guide for Secure Internet-Facing Deployments

Many Sage CRM installations today are securely accessed over the Internet rather than through a VPN. This is perfectly acceptable provided the server hosting Sage CRM has been properly hardened and follows modern security best practices.

Security is not achieved through a single setting—it is the result of multiple layers of protection. This guide provides a practical checklist that administrators can use when deploying or reviewing a Sage CRM installation.

**Please note this is advice that you or your partner must implement and CRM Together have no responsibility for how this is implemented or whether it works for you. **

---

1. Keep Everything Up to Date ⭐⭐⭐⭐⭐

Why?

The majority of successful attacks exploit vulnerabilities that have already been fixed by software vendors.

Ensure the following are always kept current:

• Windows Server
• IIS
• Sage CRM
• SQL Server
• .NET Runtime
• Antivirus definitions

Checklist

☐ Enable Windows Updates

☐ Install Sage CRM updates and hotfixes

☐ Patch SQL Server regularly

☐ Remove unsupported operating systems

---

2. Use HTTPS Everywhere ⭐⭐⭐⭐⭐

Never allow users to access Sage CRM over HTTP.

Instead, install a trusted SSL certificate and force all traffic to HTTPS.

Example:

https://crm.company.com/crm

instead of

http://crm.company.com/crm

How to do it

Within IIS:

• Install an SSL certificate.
• Bind the website to HTTPS (port 443 or another secure external port).
• Redirect HTTP requests to HTTPS.
• Renew certificates before expiry.

Free certificates are available through Let’s Encrypt, although many organisations prefer commercial certificates or those issued by their internal PKI.

Checklist

☐ Trusted SSL certificate installed

☐ HTTP redirected to HTTPS

☐ Certificate renewal process documented

---

3. Disable Old TLS Versions ⭐⭐⭐⭐⭐

Older encryption protocols such as:

• SSL 2.0
• SSL 3.0
• TLS 1.0
• TLS 1.1

contain known weaknesses.

Modern browsers support TLS 1.2 and TLS 1.3, which should be the only enabled protocols.

How to do it

Microsoft recommends disabling legacy protocols using either:

• Group Policy
• PowerShell
• Registry settings
• IIS Crypto (from Nartac Software)

IIS Crypto is widely used because it provides a simple interface for enabling Microsoft best practices without manually editing the registry.

After changes, reboot the server.

Checklist

☐ TLS 1.2 enabled

☐ TLS 1.3 enabled (where supported)

☐ TLS 1.0 disabled

☐ TLS 1.1 disabled

☐ SSL disabled

---

4. Disable Weak Cipher Suites ⭐⭐⭐⭐⭐

Even when TLS is enabled, some cipher suites are considered weak.

Examples include:

• RC4
• DES
• 3DES
• NULL ciphers
• EXPORT ciphers

These should all be disabled.

How to do it

Again, IIS Crypto is one of the easiest methods.

Windows Server also allows cipher ordering through:

Computer Configuration
 └ Administrative Templates
     └ Network
         └ SSL Configuration Settings

Prefer modern ciphers such as:

• AES-256-GCM
• AES-128-GCM
• ChaCha20-Poly1305 (where supported)

You can verify your configuration using:

https://www.ssllabs.com/ssltest/

A rating of A or A+ is a good target.

Checklist

☐ RC4 disabled

☐ DES disabled

☐ 3DES disabled

☐ Modern AES cipher suites enabled

☐ SSL Labs score checked

---

5. Remove Unnecessary IIS Features ⭐⭐⭐⭐☆

Many IIS features are installed by default but are not required by Sage CRM.

Reducing the number of installed components reduces the attack surface.

Disable features such as:

• FTP Server
• WebDAV (unless required)
• Sample applications
• Unused authentication providers
• Legacy ISAPI filters

How to do it

Open:

Server Manager

Remove unused IIS Roles and Features.

Review installed IIS modules regularly.

Checklist

☐ FTP removed

☐ WebDAV removed if unused

☐ Sample applications removed

☐ Unused IIS modules removed

---

6. Disable Directory Browsing ⭐⭐⭐⭐☆

Directory browsing allows visitors to view files within a folder if no default page exists.

Although Sage CRM does not require directory browsing, leaving it enabled can expose unnecessary information.

How to do it

Within IIS Manager:

Site
    Directory Browsing
        Disable

Checklist

☐ Directory browsing disabled

---

7. Apply Request Filtering ⭐⭐⭐⭐☆

Request Filtering blocks suspicious requests before they reach Sage CRM.

It can help prevent attacks involving:

• Double extensions
• Long URLs
• Dangerous file types
• Invalid HTTP verbs

How to do it

Within IIS:

Site
    Request Filtering

Configure limits appropriate to your environment and block unnecessary HTTP methods if they are not required.

Checklist

☐ Request Filtering enabled

☐ File upload limits reviewed

☐ Dangerous verbs restricted where appropriate

---

8. Enable HTTP Security Headers ⭐⭐⭐⭐☆

Security headers instruct browsers how to safely interact with your application and can reduce the impact of certain attacks.

Recommended headers include:

• Strict-Transport-Security (HSTS)
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

Some headers, such as Content-Security-Policy (CSP) or X-Frame-Options, may affect Sage CRM customisations or embedded content. Test these carefully before enabling them broadly.

How to do it

Headers can be configured in:

• IIS
• ARR/Reverse Proxy
• Nginx
• Apache
• Cloudflare

Example:

Strict-Transport-Security:
max-age=31536000;
includeSubDomains

Checklist

☐ HSTS enabled

☐ Browser security headers reviewed

☐ Configuration tested after changes

---

9. Protect SQL Server ⭐⭐⭐⭐⭐

SQL Server should never be directly accessible from the Internet.

Only the Sage CRM web server should communicate with SQL Server.

Best practices

• Block SQL ports at the firewall.
• Use Windows Firewall.
• Use strong SQL passwords or Windows Authentication where possible.
• Remove unused SQL logins.
• Apply SQL Server updates regularly.

Checklist

☐ SQL inaccessible from Internet

☐ Firewall enabled

☐ Strong authentication

☐ SQL patched

---

10. Limit Firewall Exposure ⭐⭐⭐⭐⭐

Only expose services that users genuinely need.

Most deployments only require:

• HTTPS (443) or another chosen external HTTPS port.

Avoid exposing:

• RDP (3389) directly to the Internet.
• SQL Server ports.
• SMB (445).
• WinRM.
• FTP.

If administrators require remote access, use a VPN, a bastion host, or Microsoft Entra Private Access rather than exposing RDP publicly.

Checklist

☐ Only HTTPS exposed

☐ RDP protected

☐ SQL hidden

---

11. Geo-Blocking ⭐⭐⭐☆☆

If every employee works within one or two countries, there is little reason to accept login attempts from the rest of the world.

Geo-blocking significantly reduces automated attacks.

How to do it

Common approaches include:

Firewall

Many enterprise firewalls support country-based rules:

• Fortinet
• Sophos
• Palo Alto
• Cisco
• SonicWall

Example:

Allow:
Ireland
United Kingdom

Block:
All other countries

Cloudflare

Cloudflare WAF allows country-based access rules without changing your server configuration.

Azure Front Door

If hosting in Azure, country filtering can be configured at the edge.

Checklist

☐ Countries reviewed

☐ Access rules implemented

☐ Exceptions documented

---

12. Web Application Firewall (WAF) ⭐⭐⭐⭐☆

A Web Application Firewall sits in front of Sage CRM and inspects incoming traffic.

It can detect and block many common attacks before they reach IIS.

Examples include:

• SQL Injection
• Cross-Site Scripting (XSS)
• Malicious bots
• Credential stuffing
• Known exploit signatures

Common WAF platforms include:

• Cloudflare WAF
• Azure Application Gateway WAF
• AWS WAF
• F5
• Imperva

Checklist

☐ WAF evaluated

☐ OWASP Core Rule Set enabled (where applicable)

☐ Logs monitored

---

13. Monitor Logs ⭐⭐⭐⭐☆

Early detection is often just as important as prevention.

Review:

• Windows Event Logs
• IIS Logs
• SQL Logs
• Sage CRM Logs
• Firewall Logs

Consider forwarding logs to a central monitoring solution such as Microsoft Sentinel or Splunk.

Checklist

☐ Logging enabled

☐ Regular log reviews

☐ Alerts configured

---

14. Regular Vulnerability Scanning ⭐⭐⭐⭐☆

Even well-maintained servers can drift from their intended configuration over time.

Schedule regular vulnerability scans using tools such as:

• Microsoft Defender Vulnerability Management
• Nessus
• Qualys
• OpenVAS

External scans can identify issues that are visible from the Internet.

Checklist

☐ Quarterly internal scan

☐ Quarterly external scan

☐ Findings remediated

---

15. Backup and Recovery ⭐⭐⭐⭐⭐

Backups are your final line of defence against ransomware, hardware failure or accidental data loss.

Recommendations:

• Test restores regularly.
• Store at least one offline or immutable copy.
• Back up both SQL Server databases and Sage CRM customisations.

Checklist

☐ Daily backups

☐ Restore tests completed

☐ Offline/immutable copies retained

---

Final Security Review

Before making Sage CRM publicly accessible, verify the following:

• ☐ Windows fully patched
• ☐ Sage CRM updated
• ☐ SQL Server secured
• ☐ HTTPS enforced
• ☐ TLS 1.2/1.3 only
• ☐ Weak ciphers disabled
• ☐ Firewall limited to HTTPS
• ☐ RDP not publicly exposed
• ☐ Directory browsing disabled
• ☐ Request filtering enabled
• ☐ Security headers reviewed and tested
• ☐ WAF considered or deployed
• ☐ Geo-blocking evaluated
• ☐ Logging enabled
• ☐ Backups tested
• ☐ Vulnerability scans performed

Conclusion

No single security measure will protect a Sage CRM deployment. The strongest defence comes from combining multiple layers of protection: a fully patched operating system, secure IIS configuration, strong authentication, careful network exposure, and ongoing monitoring.

By working through this checklist, organisations can significantly reduce their attack surface while continuing to provide secure, reliable access to Sage CRM for users both inside and outside the corporate network.