Security in Aternity SaaS

Aternity's security extends to both the server side and the Agent for End User Devices installed on your end user devices, applying a broad set of methods across all access points in the system.

Aternity offers secure connections to monitored devices and to users of the system

For details about end user privacy, see how Aternity stores PII (personally identifiable information).

Aternity's security measures include:

Route Port Description

Agent for End User Devices collects and sends data to Aternity


The files (DLLs and EXEs) of the Agent for End User Devices are digitally signed to ensure no tampering. It also uses several anti-hack security measures, including ASLR (randomizing memory addresses), DEP (validating code is run from expected locations) and SEH (ensuring only valid exception handlers).

When sending data, the Agent reports securely to Aternity via HTTPS. The Agent uses TLS 1.2 on devices with .NET 4.5 or later.

Agent setup


The Agent setup package is digitally signed to guarantee the files are genuine.

Secure installation of the Agent for End User Devices
Aternity Recorder


The Aternity Recorder located on a monitored device is only active when you gather data to create custom activities, and even then, it is only active on that device for the limited time during the actual recording, with the explicit approval and interaction of the user on that device for that time.

Alternatively, for maximum security, you can configure the setup of the Agent for End User Devices to exclude the Recorder entirely from all monitored devices. If you create your own custom activities, which require the Recorder to find the start and end events of an activity, you can designate a specific device to perform those recordings for that time.

Access to Aternity (local user or SSO)


Aternity SaaS users access securely via HTTPS (learn more).

Optionally, for complete control of the security of signing in, you can deploy SSO. Single Sign-On (SSO) brings the most secure access to Aternity by bypassing Aternity's sign in screen, and authenticating with your enterprise's chosen identity provider (IdP) just once using passwords, two-factor authentication (2FA), or even biometrics. Every time you access Aternity as an SSO user, it automatically reroutes you securely to the IdP, and then after authentication, it routes you back to your Aternity home page as a signed in user. SSO uses the secure SAML 2.0 protocol to delegate the entire authentication process to the IdP.

Learn more.

Access your Aternity homepage using SSO

Access to Aternity

Account administrator can decide who can or cannot access Aternity. In other words, from what IP addresses users can connect to Aternity. So, some IP addresses can be filtered and restricted to access Aternity. This way, you control who can see the data in Aternity dashboards.

This configuration can be done in Edit Acounts screen. You can define the allowed subnets or restrict access to residents only.

For more information and configuration, contact Aternity SaaS Administration.

REST API queries


Analysts can send REST API queries to view Aternity data directly via HTTPS (port 443).

Automatic emails

587 outbound

With Aternity SaaS, its email server comes automatically configured with Amazon's simple email service (SES).

Aternity sends emails via its configured email server


Determined by ServiceNOW server

Integrate Aternity with ServiceNow if you want to automatically route service desk alerts (SDA) to ServiceNow. Enter the details of accessing your ServiceNow, and also the username and password of a special 'service' user which is only for Aternity to send SDAs to the Aternity App for ServiceNow.

Aternity communicates with the Aternity App for ServiceNow based on the settings of the ServiceNOW server.

Aternity can send service desk alerts in several formats, including directly to your ServiceNow

Automatic timeout

By default Aternity has an automatic timeout, logging you out if the session has been idle for more than 30 minutes (or 3.5 hours in advanced dashboards).

Aternity's extensions security permissions include:

Security Aspects Description

Aternity Chrome extension (Agent)

The addon does NOT send any info to any website. Aternity only collects data from end user devices for further performance analysis. It does not perform any outside communication for any site.

Add Aternity extensions to your white list or do not deploy them at all (by disabling the Chrome Extension Policy monitor prior to deploying the Agent). Note that it will cause losing most Chrome monitoring capabilities.

Aternity Chrome extension (WAC)

The addon does NOT send any info to any website. Aternity allows creating activities for further performance analysis. It does not perform any outside communication for any site.

Aternity Chrome extension permissions

management: The permission is used for communicating with the WAC extension

nativeMessaging: The permission is used for exchanging messages with native applications, for communicating with the Agent

webNavigation: The permission is used for receiving notifications about the status of navigation requests on fly, for measuring web pages loading time.

webRequest: The permission is used for observing and analyzing traffic info, for measuring network times during web pages loading time.

Tabs: The permission is used for managing the state of all frames in all tabs, and providing tab events so that they can be used when creating activities.

idle: The permission is used for detecting any change in the device's idle state.

Host Permission (URL patterns): Aternity requires permissions to all websites to detect the usage.