Brian McKeiver's Blog

27 Ways to Harden Your Kentico 13 Site Before End of Support

Introduction

Kentico 13 reaches end of support on December 31, 2026. Your site won’t stop working the day after that, but Kentico will stop shipping hotfixes for any newly discovered security vulnerabilities. That’s the part that should actually worry you. You can review Kentico’s full support lifecycle policy here: https://www.kentico.com/customers/supportcenter/support-lifecycle

So what do you do between now and then? You harden what you’ve got. Below are multiple things you can do right now to lock down your Kentico 13 site and shrink your attack surface before support runs out. None of these guarantee you’re bulletproof, but together they make you a much harder target. 

And if all of this has you wondering whether it’s time to migrate from Kentico 13 to Xperience by Kentico, check out my Kentico Migration Cost Calculator for a quick cost estimate.


Kentico 13 end of technical support checklist


Kentico Specific Settings/Configurations

  1. Patch to the latest hotfix right now. At the time of writing, that is 13.0.214. You can download the latest at https://devnet.kentico.com/download/hotfixes. There is no reason to not be up to date as of right now. The most recent moderate security update was August 19th, 2026. I’m guessing most of you reading this currently need to update. 

  2. Plan to patch to the latest hotfix as of mid-December 2026. Make the time in your schedule / deployment plan to get another hotfix out the door before the holiday break. Even if there is nothing that actually happens, at least you have the time built into your schedule now.

  3. Lock down the admin tool of Kentico 13 to internal use only. Block requests from the outside world. Use IP restrictions for this if you can, Azure makes it quite easy.

  4. Rename / Redirect the /admin route. This can easily be changed to allow a custom admin route so people can’t find your admin tool as easily. Make it something custom like for BizStream we might do /admin-bzs where bzs is a short code for our organization and somewhat unique.

  5. If you are not using Kentico’s Content Staging module, completely disable it by following the Content Staging security documentation on how to do so, or if you really want to be sure, remove the entire endpoint .ashx file.

  6. If you are using Kentico’s Content Staging module, make sure you have it set to the highest level of security and are patched up to the latest version of Kentico 13. That means you are using x509 certs in the settings configuration to securely communicate between instances. https://docs.kentico.com/13/deploying-websites/content-staging/using-x-509-authentication

  7. Require MFA for Kentico administrators. K13 supports TOTP-based MFA for the administration interface, yet many older installations still rely exclusively on usernames and passwords. SSO with an enterprise-class IDP is possible as well.

  8. If you are using username and password built-in authentication in K13, make sure that there are strong password requirements. Enable password expiration. Set the password format to the strongest security level of PBKDF2 https://en.wikipedia.org/wiki/PBKDF2

  9. Limit the number of invalid sign-in attempts by enabling the Maximum invalid sign-in attempts and having the value set to something limited like 5 to 10 attempts. More invalid attempts past that number will lock the admin user account out.

  10. Audit and review all global admin accounts. If there are any stale admin accounts, DISABLE them. Do NOT delete them (due to macro signature identities).

  11. Enable the security debug option in the Kentico Event Log. The security debug allows you to view user security checks performed within the context of the administration interface.

  12. Disable autocomplete in the sign-in form of the Kentico admin tool. This forces users to type in the proper credentials, or better yet, use a password manager to enter them.

  13.  Triple check your Kentico Media Library security settings. Ensure all libraries have proper permissions, do NOT leave them with the out of the box setting which leaves this functionality vulnerable. Ensure only admin accounts or specific roles have / need write permissions to each library. Yes, check each one, one at a time.

  14.  If not using it, disable the automatic REST API service that is built into the Kentico admin tool.

 

Azure App Service Specific Settings/Configurations

 I am assuming most people reading this are running in Azure or locally via on-premises IIS servers. The items in this category basically apply to both of those hosting types.

  1. Enable backups in Azure App Service. Most people forget to do this, not sure why. It is off by default in most instances. Enabling backups allows you to restore quickly if something goes wrong.

  2. Ensure there is a Web Application Firewall on top of your entire application. If you are in Microsoft Azure, I highly recommend Azure Front Door https://learn.microsoft.com/en-us/azure/frontdoor/create-front-door-portal?tabs=quick, or another great option is Cloudflare. However, if this would be a new change to your Kentico site, there are some nuances to adding it. The most important ones are:
    • The Kentico admin tool needs to be able to call out to the Kentico License server to continually validate your subscription license. Follow the docs on how to whitelist the URL.

    • The Kentico admin tool also needs to be able to call itself to ensure Scheduled Tasks run properly

    • WAF’s tend to like blocking the admin scripts to make the Pages app run correctly. You may need to whitelist the script URLs to allow those to get through the WAF depending on your setup.

  3. Ensure that in the production service your environment variable of DOTNET_ENVIRONMENT and/or ASPNETCORE_ENVIRONMENT is set to Production (and not Development).

  4.  Azure App Service FTP service - Change the configuration to FTPS only or Disabled if you do not use FTP for deployment.

  5.  Use Azure Key Vault for secrets management. App Service environment variables frequently accumulate database credentials, API keys, SMTP credentials, and other secrets over the lifetime of a Kentico site. Key Vault references let the App Service consume those values without putting the actual secret directly into the application configuration.

  6.  Make sure Remote Debugging is disabled. Remote Debugging is useful when troubleshooting, but Microsoft specifically recommends turning it off in production because it requires additional inbound access.

  7.  Use Managed Identity for connections to other Azure services. Azure SQL, Key Vault, Storage, and other services can often authenticate the App Service without storing usernames, passwords, or client secrets.

  8.  Log access restriction activity. App Service has an IPSecurity Audit logs category specifically for requests that match access restriction rules. That can help you see who is trying to reach endpoints you deliberately blocked.

 

.NET Code Specific Settings/Configurations

The items here are more around the font-end aspect of the MVC live site itself and not the Kentico 13 admin tool.

  1. Follow the Guide to Secure .NET Development with OWASP Top 10, which is found at https://learn.microsoft.com/en-us/training/modules/owasp-top-10-for-dotnet-developers/ for your application code base.

  2.  Ensure your .NET runtime and dependencies are current. If you are in modern .NET get to the latest LTS (Long term support), which is .NET 10.0.x. It has been refreshed with the latest update as of July 14, 2026, https://support.microsoft.com/en-us/servicing/dotnet/net-10/2026/net-10-0-update-july-14-2026

  3.  Update your NuGet packages to ensure you solve any known security vulnerabilities.

  4.  Check your front-end stack of JavaScript files for version updates. Dependencies like jQuery, Angular, Vue, Astro, Alpine, all get forgotten easily over time and all are updated frequently.

  5.  Make sure your production environment really behaves like production. Debug mode, developer exception pages, go check that right now your environment settings, applicationsettings, and Kentico admin tool’s web.config all say production and not debug mode. The default Kentico setting is debug is true. We find this all the time set incorrectly. Make sure debug is set to false.

 

Conclusion

That’s 27 ways to harden your Kentico 13 site before support runs out. Work through the list, knock out whatever you haven’t already covered, and you’ll be in much better shape heading into 2027. And if this whole exercise has you thinking it might just be time to move off Kentico 13 for good, check out my Kentico Migration Cost Calculator for a quick, no-strings cost estimate to move to Xperience by Kentico.