Skip to content

Security guide

Profinity controls and monitors critical hardware, including industrial equipment, battery management systems, motor controllers, and charging systems. Treat security as a priority throughout deployment. A weak configuration can damage equipment, create a safety hazard, or stop the system.

This guide covers the security controls that matter when deploying and operating Profinity, and links to the pages for each feature.

Security areas

Profinity V2 provides control over critical industrial, automotive, and energy systems. Securing it involves six areas.

HTTPS protects the network path, Docker settings isolate the container, and the security files and keys hold the secrets. Scripting controls what code runs with Profinity's privileges, user accounts limit who can do what, and Kiosk Mode controls unattended displays. The checklist at the end summarises the steps for a production deployment.

HTTPS configuration

HTTPS is on by default, but Profinity also listens on HTTP. When Profinity is accessed over a network, turn on Redirect all HTTP traffic to HTTPS so that all communication uses HTTPS. Without it, usernames, passwords, API tokens, and system data can be intercepted.

Profinity supports HTTPS configuration through the Profinity Web settings. Use a certificate from the Windows Certificate Store for a Windows deployment, or a .pfx or .p12 certificate file for a cross-platform deployment.

For production, turn on Redirect all HTTP traffic to HTTPS so that every connection uses encryption. Use certificates from a trusted Certificate Authority (CA), and plan certificate renewal so that an expiry does not interrupt the service. Binding HTTP to localhost only, with the IP address for HTTP setting on the Profinity Web page, and requiring HTTPS for remote access keeps credentials off the network.

Profinity Mobile connects over the local network, so keep the HTTPS port reachable from the networks that phones use. For the certificate steps, refer to Profinity Web.

Docker security

The Profinity image runs as the non-root app user, so a container already runs without root privileges. Keep it that way, and make sure the host directory mounted at /var/lib/prohelion/profinity is writable by that user. Set CPU and memory limits on the container to prevent resource exhaustion. Use Docker networks to isolate Profinity from other services, and use only official Profinity images from Prohelion repositories.

Apply these controls:

  • Give mounted volumes that hold profiles, configurations, or logs file system permissions that match their sensitivity.
  • Keep the config folder writable. Profinity saves config.yaml and security.yaml when settings, users or roles change.
  • Encrypt backups of sensitive data and keep them in a secured location.
  • Publish only the ports you need to the host, and restrict access to them with a host firewall.
  • Place a reverse proxy in front of Profinity for production deployments.

For deployment details, refer to Install Profinity with Docker.

Protect the security files and keys

security.yaml in the config/ folder of the artefacts directory holds users, roles, two-factor secrets, and the keys that sign sessions and encrypt secrets. Restrict read access to that folder to the account that runs Profinity. Include security.yaml in encrypted backups, and never commit a file that contains real keys to source control.

In a Docker container, security.yaml and its keys are written to the container's own storage when PROFINITY_HOME does not match a mounted volume. Replacing the image then regenerates the keys and resets Profinity to the default administrator account, so mount a volume at the default artefacts directory, /var/lib/prohelion/profinity, and do not set PROFINITY_HOME for a normal installation.

Scripting security

Profinity scripts execute with the same security permissions as Profinity itself. A script can:

  • Access all system resources available to Profinity.
  • Send and receive CAN bus messages.
  • Modify system configuration.
  • Control connected hardware, including batteries, chargers, and motor controllers.

Scripting is switched off by default. An administrator turns it on under ADMIN > System Configuration, with Enable C# scripting, Enable Python scripting, or Enable Lua scripting for each language to allow. The setting is available only when the licence includes the Scripting feature, which the Desktop, Server, and Enterprise editions include. An unlicensed instance does not include scripting.

Enable it only when the use case needs it, and review script code before deployment, especially scripts from external sources. Keep production scripts under version control with a review process, and audit active scripts regularly. When Profinity runs as a service, give it the minimum operating system permissions it needs.

Document each script and its purpose for security reviews. For the scripting pages, refer to Profinity Scripting.

User account security

Default credentials

Change default credentials immediately

Which installations include a default administrator account depends on the installation type and licence. Refer to Who can sign in, by installation type for the full list. On Linux, macOS, Docker, and the Windows service, and on the Windows desktop application once a licence with the Profinity Server feature is applied, the default account uses these credentials:

  • Username: admin
  • Password: password

Profinity asks for a new password at the first sign-in with these credentials, and leaving the default credentials active exposes the system to unauthorised access.

The Windows desktop application creates this account only when a licence with the Profinity Server feature is applied. For who can sign in on each installation type, refer to Who can sign in, by installation type.

User account practices

Create an account for each person or system that needs access instead of sharing the administrator account. Enforce a password policy that suits the organisation, as described in Password policy. Rotate passwords on production systems, and disable or remove accounts that are no longer needed. Creating user accounts and roles needs the Profinity Server feature.

Sign-in, two-factor, and session controls

Profinity offers these sign-in and session controls:

  • A site sign-in method, either Local or single sign-on (SSO)
  • Two-factor authentication for local users
  • A password policy and a session policy
  • Security Information and Event Management (SIEM) export
  • Service accounts with long-lived tokens

Two-factor authentication needs the Server or Enterprise edition, and SSO and System for Cross-domain Identity Management (SCIM) need the Enterprise edition. Refer to SSO and sign-in method, Two-factor authentication, SCIM and SIEM, and Service accounts.

Security roles

Profinity uses 27 granular permissions grouped into roles, and users receive assigned roles. Profinity has no security groups or per-user permission lists. The Users & Groups menu under ADMIN manages users and roles, and its name is left over from older security groups. A security file from an earlier version that holds groups is converted to roles when it loads. Assign users only the permissions their work needs.

Give monitoring accounts read-only roles for dashboards and the Tag Explorer, and use individual administrator accounts. Review accounts and role assignments periodically.

The Send CAN messages permission lets a user inject CAN frames onto the bus, so assign it only to trusted users. Refer to Roles and permissions for the full catalogue and the built-in Administrators role, and Managing users for user management.

Kiosk Mode security

Kiosk Mode signs a selected user in automatically without a login, which needs careful configuration. Profinity does not restrict which enabled user is selected, including administrators, so anyone at the kiosk inherits that user's permissions. Use a dedicated user with only the view permissions the display needs, such as a read-only role, and review that user's permissions regularly.

Monitor kiosk access through the SECURITY| login entries in the Profinity logs. Secure the device physically, because Kiosk Mode bypasses the login page. In production, isolate the device on its own network segment, and disable Kiosk Mode when you no longer need it. Refer to Kiosk Mode for the configuration.

Production deployment checklist

Before deploying Profinity in a production environment:

  • Change the default administrator password.
  • Configure HTTPS with valid certificates and turn on the HTTPS redirect.
  • Create individual user accounts and assign minimum permissions.
  • Apply a licence with the Profinity Server feature if you need remote access, users, or roles.
  • Restrict read access to security.yaml and encrypt backups of it.
  • Review and audit all active scripts, and disable scripting unless it is required.
  • Configure firewall rules to restrict access to Profinity ports.
  • Review the logs on a schedule and forward them to your monitoring system.
  • Back up configurations and profiles on a schedule, and test a restore.
  • Write down the security configuration and who may change it.
  • If using Docker, mount a volume at /var/lib/prohelion/profinity and follow the Docker security guidance.
  • Review Kiosk Mode and disable it unless it is needed.

Next, configure HTTPS in the Profinity Web settings.