Kepware KEPServerEX Security Guide: Hardening Users, OPC UA Endpoints and the API

Kepware Server, the PTC connectivity platform formerly sold as KEPServerEX, often sits between every PLC on a line and every historian, MES and cloud platform above it, so one loosely configured instance can expose read and write access to a whole plant. The settings that decide who can connect, what they can change and whether traffic is encrypted are all customer-side choices: the User Manager, the OPC UA server endpoints and trust lists, the Configuration API, the project file format and the logs. This guide walks through each of those, in the order an OT engineer or integrator would harden a new or inherited installation, and shows how to roll changes out without stopping production. It is for OT engineers, integrators and OT security teams. For the OPC UA protocol itself (SecureChannel, Session, SecurityPolicy and the Global Discovery Server) read the OPC UA Security Guide first; this page stays on the product settings.

This is an independent guide from NHI Mgmt Group, based on PTC's public Kepware Server documentation as of November 2026. It is not sponsored or reviewed by PTC. Product features change, so confirm settings against PTC's current documentation.

Key takeaways

• The User Manager is the access control list. Every OPC UA, API and ThingWorx client maps to a user and group whose permissions decide whether it can modify the project, change server settings or write tags, so build one least-privilege group per client type.
• Keep anonymous login off. PTC ships the OPC UA server interface with Allow anonymous login set to No; keep it that way and give each client its own credential.
• Endpoints decide encryption. Enable only the OPC UA endpoints you need, on the right network adapter, with Basic256Sha256 or the AES policies and Sign and Encrypt, and trust client certificates one by one.
• The Configuration API is an admin interface. Turn HTTP off, use HTTPS with a trusted certificate, set CORS to named origins and give automation its own account with only the rights it needs.
• Protect the project and the logs. Save projects as encrypted .SOPFSLPF files, send Event and Audit logs off the host, and restrict who can reset them.

Where Kepware Server sits and what to protect

Kepware Server runs on Windows as a service and uses device drivers to poll controllers over industrial protocols, then republishes that data through client interfaces such as OPC UA, OPC DA, the ThingWorx native interface and IoT Gateway agents. PTC documents the current product as Kepware Server, with release notes up to 7.1.271.0 in the help system as of November 2026, and publishes a Secure Deployment Guide for Kepware Server for version 7.0. It usually sits at Purdue level 2 or 3, or in an industrial DMZ, so it is both a data source for IT and a path into control networks.

Treat the instance as four separate attack surfaces, each with its own owner:

The Windows host matters as much as the product: anyone with local administrator rights on it can change the service, read the ProgramData folder and stop logging. Harden and patch it to your server baseline and record it as an OT asset (see the OT Asset Visibility Guide).

User Manager: users, groups and permissions

The User Manager ships with four built-in groups (Administrators, Anonymous Clients, Server Users and ThingWorx Interface Users), each containing one built-in user (Administrator, Data Client, Default User and ThingWorx Interface). The built-in users and groups stay in place and cannot be disabled, renamed or have their descriptions edited, and the Administrator's settings are fixed, so the hardening approach is to add your own groups and users with narrow rights and route every client through them.

Permissions are set per group in seven categories: Project Modification, Server Permissions, I/O Tag Access, System Tag Access, Internal Tag Access, Browse Project Namespace and Event Log. Server Permissions are not available to the Anonymous Clients group, and the Event Log permissions default to Allow, so review them deliberately.

• Follow PTC's data-access pattern: PTC's Secure OPC UA Tunneling connectivity guide creates a dedicated OPC UA group with Project Modification and Server Permissions set to Deny All and tag access allowed. Start from that and narrow tag access further where the client only reads.
• Passwords: the User Manager requires case-sensitive passwords of 14 to 512 characters with mixed case, numbers and special characters. Keep client passwords in a secrets vault and rotate them in the client's maintenance window.
• Active Directory users: where the User Manager is linked to Active Directory users, their passwords are managed by the domain, so the domain's joiner, mover and leaver process covers them. Use AD for people and local users for machine clients.
• After upgrades and imports: PTC advises reviewing User Manager permissions after an upgrade or a project import. Add that review to the change checklist.
• Disable to contain: disabling a custom group disables all its users, and restoring it returns them to their previous state.

Each client account here is a non-human identity with an owner, a credential and an expiry. Record them in your NHI inventory and review them with the process in the OT and ICS Identity and Access Guide.

OPC UA server interface and endpoints

Two places control OPC UA access. Project Properties, OPC UA tab, sets the server interface behaviour; the OPC UA Configuration Manager sets the endpoints, security policies and certificate trust.

The OPC UA project properties that matter for security are:

• Enable (Server Interface): turn the interface off on instances that have no OPC UA clients; when disabled, the remaining OPC UA properties are disabled too.
• Allow anonymous login: PTC sets this to No by default "to disallow anonymous access and require credentials to log in". Keep it at No in production.
• Max. connections: range 1 to 256, default 128. Set it to the number of known clients plus headroom so a runaway or hostile client cannot consume every session.
• Log diagnostics: sends OPC UA stack diagnostics to the OPC Diagnostics viewer. Use it for fault finding only.
• Administrator logins: the Administrator can log in over OPC UA when a password is set. Give OPC UA clients their own users instead, and alert on any OPC UA session that uses an administrator account.

For endpoints, PTC's connectivity guide shows the hardened pattern: enable only the endpoint needed for the remote connection, bind it to the network adapter that faces the client zone, select Basic256Sha256 and require Sign and Encrypt on the client channel. The guide uses TCP 49320 as the default endpoint port and suggests moving to a non-default port; a port change reduces casual scanning noise but is not an access control, so the firewall rule and the trust list still do the real work. Where both sides support them, the AES policies (Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss) are also current; disable None and the deprecated Basic128Rsa15 and Basic256 policies.

Certificates and trust

PTC's connectivity guide states that the pre-loaded self-signed OPC UA certificate is meant for testing and proof-of-concept work, is valid for three years and must be managed by the customer. Trust is manual by design: a client certificate appears after its first connection attempt and an administrator moves it to trusted in the Trusted Clients tab of the OPC UA Configuration Manager; outbound connections from the OPC UA client driver need the remote server's certificate in Trusted Servers.

Every certificate in that table is a machine identity with a private key and an expiry date. Put them in the same inventory and renewal process as other site certificates, as described in the Machine Identity, PKI and Certificate Lifecycle Guide, because an expired OPC UA certificate stops data flow and creates pressure to fall back to an unsecured endpoint.

Configuration API, console and runtime settings

The Configuration API is a REST interface that can change the whole project, so treat it like any other administrative API (see the API Security Guide for general controls). The Configuration API Service settings give you the following controls:

• Enable: when set to No, the service runs but does not bind to its HTTP or HTTPS ports. Leave it off on instances that are not managed by automation.
• Enable HTTP: set to No so only encrypted traffic is accepted. PTC states that HTTP should only be used on internal networks secured by other methods, that authentication data should not be exposed over HTTP, and that the HTTP port should be blocked at the firewall.
• HTTPS and certificate: HTTPS requires a REST client supporting TLS 1.2 or higher, and access from outside a secure network requires a trusted certificate. The server sends HTTP Strict Transport Security in its responses.
• Enable Token-Based Authentication: allows bearer tokens, which supports single sign-on through your identity provider. The bearer authentication settings store only public keys used to validate JSON Web Tokens.
• CORS Allowed Origins: a comma-separated list. PTC's example uses a wildcard; in production list only the origins of the tools that call the API, or leave it empty if no browser-based tool needs it.
• Who can change these settings: Administrators or users with Modify Server Settings; keep that right off automation accounts.
• Transaction log: Persistence Mode defaults to Memory with 1000 records. Switch to Single File or Extended Datastore so API changes survive a restart, and keep Verbose off unless troubleshooting, because it adds request and response bodies.

Two further settings pages complete the picture. Under Settings, Configuration, Max Concurrent Configuration Connections (default 10) and Idle Session Timeout (default 60 seconds) limit how many consoles can be attached and how long an unattended one stays open; lower the connection limit to the number of engineers who genuinely work on the instance. Under Settings, Runtime Process, keep Selected Mode at System Service (the default). Switching mode restarts the server and resets user-configured DCOM settings to their defaults, so plan any change in a maintenance window and recheck DCOM afterwards if OPC DA clients are still in use.

Project files, logs and audit

The project save options come in three formats. .SOPFSLPF is encrypted and is the format PTC recommends; .OPFLPF is binary and unencrypted; .JSON is human readable and PTC describes it as a less secure option for use only where other protections are in place. Encryption is on by default for new projects and takes a 14 to 512 character password, changed under Project Properties, General, Project File Encryption. The server also keeps automatic project copies under C:\ProgramData\PTC\Kepware Server\, so restrict that folder to the service and administrators and include it in backup scope. Store the project password in your vault alongside the OT backup set described in the OT Backup, Recovery and Golden Image Guide.

The log settings cover five logs, each with its own persistence settings:

PTC notes that the log is only useful if its contents are protected and recommends using the User Manager to restrict who can change log properties or reset the log. Max records defaults to 25,000 in Memory and Single File modes, and Extended Datastore keeps files for at least 30 days by default. The Event Log service runs as SYSTEM and cannot reach mapped drives, so use UNC paths for remote log locations, and watch the Windows Event Viewer for persistence errors.

Implementation roadmap

1. Inventory: list every Kepware instance, version, host owner, enabled client interfaces, OPC UA endpoints and policies, User Manager groups and Configuration API state. Export the current project as an encrypted backup before any change.
2. Build groups in parallel: create the least-privilege groups and per-client users without changing existing access, and agree with each client owner which tags they read and write.
3. Pilot one client: add a Sign and Encrypt endpoint with Basic256Sha256 or an AES policy next to the existing one, move one read-only client to it with its own user and trusted certificate, and watch the Event Log and the client for a full production cycle.
4. Move clients in waves: migrate the rest client by client in maintenance windows, then disable the old endpoint, confirm Allow anonymous login is No and remove unused trusted certificates.
5. Lock down administration: turn off Configuration API HTTP, import trusted certificates, set CORS and token authentication, reduce concurrent configuration connections and give each engineer a named administrator account.
6. Protect and monitor: switch to .SOPFSLPF, restrict ProgramData, forward Event and Audit logs, and subscribe to the PTC Advisory Center so vendor security updates go through your OT Patch Management Guide process promptly.

Rollback: keep the pre-change encrypted project and a note of the previous endpoint and trust list for each step. If a client fails after a change, re-enable its previous endpoint or permission for that client only, record a dated exception and fix the client, rather than turning anonymous access back on for everyone.

Small versus large sites: a single line with one instance can be hardened in an afternoon by the integrator, with certificates trusted individually. A multi-site estate with dozens of instances should template the User Manager and endpoint settings, drive changes through the Configuration API from a controlled pipeline, and issue OPC UA certificates from an OT CA so trust can be managed centrally.

Detection and measurement

Forward the Event and Audit logs and the host's Windows logs to the OT monitoring platform or SIEM, and pair them with passive network monitoring of the endpoint ports (see the OT Network Security Monitoring Guide). Alert on:

• new client certificates arriving for trust outside a change window;
• OPC UA sessions using an administrator account, or failed logins in bursts;
• Configuration API calls from hosts other than the approved automation server, or any HTTP (unencrypted) API traffic;
• project saves, user or group changes and log resets outside change windows;
• service stops, mode changes or newly enabled client interfaces.

Framework mapping

Common failure patterns

• One shared account for every client: historians, dashboards and HMIs all log in as the same user with write access, so a credential leak from the least important client gives setpoint control.
• The commissioning endpoint never removed: an unsecured endpoint added to get a client working stays enabled for years and new clients use it because it is easiest.
• Trusting whatever certificate appears: moving every rejected certificate to trusted without checking the thumbprint turns certificate authentication into a formality.
• Configuration API left on HTTP with wildcard CORS: credentials cross the network in clear text and any web origin can call the API from an engineer's browser.
• Projects saved as JSON in shared folders: device addresses and driver credentials become readable by anyone with share access, and changes go untracked.

Practitioner checklist

• Confirm Allow anonymous login is No on every instance and turn the OPC UA interface off where no clients use it.
• Create least-privilege User Manager groups per client type and one user per client application.
• Enable only the OPC UA endpoints you need, on the client-facing adapter, with Basic256Sha256 or AES policies and Sign and Encrypt.
• Replace install-time self-signed certificates and trust client certificates only after checking thumbprints.
• Turn Configuration API HTTP off, import a trusted certificate, set named CORS origins and use token-based authentication.
• Give each engineer a named administrator account and reduce concurrent configuration connections.
• Save projects as encrypted .SOPFSLPF and restrict the ProgramData folder.
• Forward Event and Audit logs centrally and restrict who can reset them.
• Track PTC Advisory Center entries and apply vendor security updates through the OT patch process.

Standards and references

• PTC: Secure Deployment Guide for Kepware Server
• PTC: Kepware Server Settings, User Manager
• PTC: Kepware Server Project Properties, OPC UA
• PTC: Connectivity Guide, Secure OPC UA Tunneling with Kepware
• PTC: Kepware Server Configuration API Service Settings
• PTC: Kepware Server Settings, Logs
• PTC: Kepware Server, Saving the Project
• PTC: Trust Center Advisory Center

Related NHI Mgmt Group resources: OPC UA Security Guide · OT and ICS Identity and Access Guide · Machine Identity, PKI and Certificate Lifecycle Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide