What to Do When a Niagara Platform Login Is Failing

Most platform login failures come from a stopped Niagara daemon, the wrong port or TLS setting, Windows account rights, certificates or a firewall. Here is how to fix each.

"Unable to connect to platform" or a login that keeps rejecting correct credentials can stop a commissioning visit or a service call dead. The causes are usually simple once you know where to look. This guide covers what the platform is, how platform logins work on Windows PCs and on controllers, and a step-by-step diagnostic sequence with fixes for each failure.

What is the Niagara platform?

Every Niagara host runs a platform daemon (on Windows, the Niagara service) beneath its stations. A platform connection from Workbench lets you manage the host: install software and modules, manage licences and certificates, copy and back up stations, and start and stop them through the Application Director.

Platform connections use:

Port	Use
3011	Platform, plain
5011	Platform over TLS (recommended)

The platform is separate from the station, which you open with an Open Station connection (Fox 1911 / FoxS 4911) or a browser.

How platform logins are authenticated

On a Windows PC or server (Workbench machine or supervisor), platform logins are checked against Windows accounts. The account must exist on the PC (or domain) and have the rights configured for Niagara platform administration, which involves Windows user groups and the Niagara admin group. Watch the "Niagara 4 Platform" video in our advanced engineering guides, which covers the Windows account name, Windows accounts and user groups, the Niagara 4 admin group, and changing the admin group.
On a JACE, IONA or other controller, platform logins use the platform credentials set at commissioning (factory-fresh JACE 8000s use tridium / niagara; see JACE default credentials).

Step-by-step diagnosis

Work through these in order. Most problems are found in the first three steps.

1. Can you reach the host at all?

Ping the host's IP address.
Check you are on the right network and subnet, and that VPNs or Wi-Fi are not routing you elsewhere.
On a controller, confirm its IP address (use the serial shell if unknown).
On a JACE 9000 with two network ports, check a default gateway is set on the first interface only.

If you cannot ping or reach the host, the problem is the network, not the login.

2. Is the platform daemon running?

On a Windows PC:

Open Windows Services and look for the Niagara service for your version. Check it is running.
If it is missing or will not start, open the Niagara Console for that version and run:

plat installdaemon

This installs the Niagara Windows service. If the daemon is corrupted or misconfigured, run plat uninstalldaemon first, then plat installdaemon.
Always use the console for the matching Niagara version: one version's console cannot manage another version's daemon.

On a controller: if the controller is booting or recovering (for example the first commissioning of a JACE 9000, which can take 15 to 20 minutes or more), the platform is not available yet. Watch the boot on the serial console.

3. Are you using the right port and TLS setting?

In Workbench's Open Platform dialog, check:

Type: Platform TLS connection on 5011, or plain on 3011 if TLS is not enabled
the host's platform may have plain connections disabled for security, in which case only 5011 works

A mismatch often looks like a login failure.

4. Certificate prompts

On a TLS connection, Workbench shows the host's certificate the first time. If you dismiss it or it has changed (for example after a controller replacement or factory reset), the connection fails.

Accept the certificate only after checking it is the expected host.
If a previously accepted certificate has changed, remove the old entry from Workbench's certificate management and connect again.
If the host's clock is badly wrong, certificate validation fails. Correct the time.

5. Credentials and account rights

On Windows:

use the Windows username exactly, including the domain where relevant (DOMAIN\user or .\localuser for a local account)
check the account is not locked or expired, and its password has not changed
check the account has the rights required for Niagara platform administration, as configured on that PC
remember Windows passwords are case sensitive

On a controller:

use platform credentials, not a station user
if credentials are genuinely lost, use the platform reset token procedure on JACE 8000 (Niagara 4.4+) and JACE 9000

6. Firewalls

Windows Defender Firewall (or third-party security software) on the supervisor may block inbound 5011/3011. Add rules for the Niagara daemon or ports.
Site firewalls and VLANs may block traffic between your laptop and the host.
JACE 9000 has its own firewall; platform access is normally allowed, but check if the platform port has been changed (see JACE 9000 firewall entries).

7. Version mismatches

Use a Workbench of the same Niagara release as the host. Connecting to a 4.15 platform with a 4.10 Workbench may fail or behave unpredictably. See Niagara Workbench versions.

8. Licence problems

A PC without a valid Niagara licence may not run the daemon or Workbench properly. Check the licence with the License Manager, and find the Host ID with nre -hostid if a new licence is needed (see how to find a PC's Host ID).

Quick reference: symptoms and fixes

Symptom	Likely cause	Fix
"Unable to connect" immediately	Daemon not running, wrong IP, firewall	Check service; `plat installdaemon`; check firewall and IP
Connection times out	Network path or firewall	Ping, check routes, VLANs, Windows firewall
Certificate error or prompt loop	New or changed certificate, wrong time	Accept or reimport certificate; correct the clock
"Authentication failed" on Windows host	Wrong Windows account, missing rights, locked account	Check account, domain format and group rights
"Authentication failed" on JACE	Station credentials used, or credentials changed	Use platform credentials; reset via shell mode if lost
Works on 3011 but not 5011	TLS not configured on platform	Configure TLS; then disable plain connections
Works for one Niagara version only	Wrong console/Workbench version	Use matching versions

Platform logins on supervisors in corporate IT environments

Supervisors on corporate networks bring extra causes of failure:

Group Policy can change local group memberships or service account rights overnight, removing the access your Niagara platform login relies on.
Password expiry on domain accounts used for platform access breaks logins after a set period.
Endpoint security software can block the Niagara daemon or quarantine files.
Server hardening can disable services or ports the platform needs.

Agree with IT which accounts are used for Niagara platform access, exclude the Niagara installation from aggressive endpoint scanning where IT policy allows, and ask to be informed of Group Policy changes that affect the supervisor. Document the arrangement so the next engineer knows.

Worked examples

"Unable to connect" to a supervisor after Windows updates

An engineer cannot open the platform on a Web Supervisor after a weekend of Windows updates. Ping works. Windows Services shows the Niagara service stopped and failing to start. In the Niagara Console for that version, plat uninstalldaemon followed by plat installdaemon reinstalls the service, which then starts normally. The station had been configured to auto-start, so it comes back with the daemon.

A commissioning engineer's credentials are rejected on a brand-new JACE 9000. The controller is still in its first-boot unpacking, which takes 15 to 20 minutes or more; the platform is not ready yet. Waiting for the boot to complete, with the serial console open to watch progress, resolves it.

Platform works from the plant room but not the office

From the office, the platform connection times out. The JACE 9000 has a default gateway configured on both Ethernet ports, so replies to the office network leave through the wrong interface. Removing the gateway from the second interface fixes it.

Information to gather before contacting support

If you still cannot connect, collect the following before calling your distributor's support team. It usually halves the time to a fix:

the host type (Windows supervisor, Workbench PC, JACE 8000, JACE 9000, IONA) and its Niagara version (nre -version on a PC)
your Workbench version
the exact error message, ideally a screenshot
the port and connection type you used (platform TLS 5011 or plain 3011)
whether ping works, and whether the Niagara service is running (on PCs)
what changed recently: Windows updates, network changes, new certificates, password changes, hardware replacement
for controllers, any serial console output captured during boot

Record platform credentials for every host in a password vault, with owner access.
Use TLS (5011) and disable plain platform connections once working.
Keep Workbench versions matched to the sites you support.
Document Windows accounts and groups used for Niagara on each supervisor.
After replacing hardware, update stored certificates in Workbench.
Keep the Niagara service set to start automatically on supervisors.

Frequently asked questions

What port does the Niagara platform use?

3011 for plain connections and 5011 for TLS connections by default.

How do I restart the Niagara daemon on Windows?

Restart the Niagara service from Windows Services. If it is missing or broken, open the Niagara Console for the version and run plat installdaemon (after plat uninstalldaemon if needed).

Windows account credentials. The account must have the rights configured for Niagara platform administration on that PC.

Why can I open the station but not the platform?

Station and platform use different ports and credentials. Check the platform port (5011/3011), the platform credentials, and that the daemon is running.

What are the default JACE platform credentials?

Factory-fresh JACE 8000s use tridium / niagara, which must be changed on first connection. Commissioned controllers use the credentials set at commissioning.

How do I check the Niagara daemon is running on Windows?

Open Windows Services and look for the Niagara service for your version. It should be running and set to start automatically on a supervisor.

No. Platform logins on Windows use Windows accounts, and on controllers use platform credentials, not station users.

Can I connect to a remote platform over a VPN?

Yes, provided the VPN routes to the BMS network and allows port 5011 (or 3011). Never expose platform ports directly to the internet.

Why does Workbench say the host is not a Niagara host?

The daemon is not running, you are connecting to the wrong IP or port, or something else is listening on that port. Check the service and the address.

The new controller has a different certificate. Remove the old stored certificate in Workbench and accept the new one after verifying it.

On Windows hosts, check the second engineer's account has the same group memberships and rights. On controllers, check they are using a valid platform account rather than a station user.

What does "plat installdaemon" do?

It installs the Niagara platform daemon as a Windows service for the version whose console you run it from. Use it when the service is missing or after removing a broken one with plat uninstalldaemon.

Why does the platform connect but the station will not?

The platform and station are separate. Check the station is running in the Application Director, and use the station's Fox/FoxS port and station credentials.

Can antivirus software block Niagara platform logins?

Yes. Endpoint security can block the daemon, its ports or its files. Agree exclusions for the Niagara installation with IT where policy allows.

Need help from a Niagara engineer?

If this guide has not solved the problem, contact the Tyrrell Products technical team on 01942 732819 or [email protected]. Tell us the controller or host type, its Niagara version and what you have already tried, and we will help you get the system running.