Information that will help you design and plan the implementation of Tachyon in your organization. This includes all the prerequisites and dependencies, which are necessary to install Tachyon.

This page is part of the design phase of implementation.

Review Design Considerations first if you need to design and plan the implementation of Tachyon in your organization.

Server requirements

Server sizing for on-premises

The specifications in the tables below are for an on-premises single-server installation supporting up to a maximum of 50000 Agent devices. A single server can have up to five Tachyon Switches to support up to 250000 devices. Each additional Switch requires an additional 6GB RAM and an additional network interface for (IP Address) with a minimum of 1Gbps.  Please see the Server Sizing reference page for more detailed sizing information for up to 250000 devices. 

Tachyon Server is recommended to be installed on a dedicated server, and can be installed on physical or virtual hardware. Best performance is achieved using a local SQL Server installation. Extra care is required to ensure performance when implementing SQL Server in a virtual environment.  

If SQL Server is shared with databases for other applications, then it must be remote (split SQL) and its CPU and RAM should be increased accordingly.

CPU cores are logical cores (physical or virtual).

Local SQL configuration

When Tachyon Server and SQL Server are installed on the same server, then the SQL Server setting maximum server memory must be set to match the value required for SQL in the table below.

Local SQLLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon Server CPU cores22335612
Tachyon Server RAM (GB)481016182232
SQL Server maximum memory1112248
Tachyon Server Network Interfaces1111111

Remote SQL configuration

When using remote (split) SQL Server(s) then the Tachyon Server is recommended to have an additional network interface for SQL traffic as explained below.

Split SQLLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon Server CPU cores1122348
Tachyon Server RAM (GB)26812141624
Tachyon Server Network Interfaces1122222
SQL Server CPU cores1111224
SQL Server RAM (GB)244668


SQL Server maximum memory1112248

For other SQL Server requirements, please see SQL Server requirements below.

Server sizing for AWS and Azure

The following tables describe the supported instance sizing for various numbers of supported clients for both single server and split server implementations, as per on-premises sizing.

When compared with the on-premise sizing guidelines these instance sizes will generally provide a greater number of CPU cores and/or memory. There is an overhead inherent in commodity virtualized cloud computing solutions which prevents them from providing exactly the same level of performance as dedicated on-premise virtualization solutions. In some cases it is also necessary to provide more of a particular resource type than required in order to get sufficient levels of another resource type due to the limited number of instance configurations offered by the cloud provider.

Instance sizing is subject to change, and may not be available in all geographic regions.

AWSLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon with local SQL Servert2.mediumm5.largem5.xlargem5.xlargem5.2xlargem5.2xlargem5.4xlarge
Tachyon Servert2.smallm5.largem5.largem5.xlargem5.xlargem5.xlargem5.2xlarge
Remote SQL Servert3.mediumr5.larger5.larger5.larger5.larger5.xlarger5.2xlarge

AzureLabUp to 500Up to 2.5KUp to 5KUp to 10KUp to 25KUp to 50K
Tachyon with local SQL ServerA2_V2A4_V2D3_V3DS12_V2DS4_V2DS4_V2F16S
Tachyon ServerA1_V2D2_V3D11_V2D11_V2D4_V3D12_V2DS4_V2
Remote SQL ServerA2_V2DS2_V2DS2_V2DS2_V2DS2_V2DS2_V2DS3_V2

AWS Network Configuration

For a split server installation it is necessary to configure an additional network interface into each server to guarantee a dedicated 1Gbps network channel between the core and the database. Enhanced networking (SR-IOV) must be enabled on both of these NICs which should be the default. Detailed steps on how to verify this are given here - Also increase the transmit (TX) and receive (RX) buffer sizes to their maximum under the network adaptor advanced properties.

Azure Network Configuration

For a split server installation it is necessary to configure an additional network interface into each server to guarantee a dedicated 1Gbps network channel between the core and the database. Enhanced networking (SR-IOV) must be enabled on both of these NICs where this is available (only on instances with 8cores or more) and must be enabled during instance creation. The additional NIC must also have accelerated networking enabled using Azure Powershell or Azure CLI. Detailed steps on how to configure this are given here - Also increase the transmit (TX) and receive (RX) buffer sizes to their maximum under the network adaptor advanced properties within the guest OS.

If connecting to an Azure based Tachyon switch via external public Azure IP addresses or Azure Load Balancers you will need to extend the default TCP timeout from 4 seconds to 15 seconds. Detailed steps on how to do this can be found here -

AWS Database Storage Configuration

Database instances (either combined or the database server in a split implementation) should use an additional Throughput Optimized SSD (ST1) EBS volume to guarantee sufficient disk performance. This is used for all database storage - data, log and tempdb. The specified instances do not support any more than one EBS volume. If you wish to separate data, log and tempdb onto separate volumes (as per Microsoft recommendations) you will need a higher spec instance for the DB server, one that will allow you to attach more volumes and allow higher throughput to disk.

For any implementation other than Lab the Elastic Block Storage (EBS) optimization must be enabled, either when the instance is originally launched or afterwards. Details on how to do this can be found here:

Azure Database Storage Configuration

Database instances (either combined or the database server in a split implementation) should have a minimum of 2 SSDs for database files. One for the Tachyon data files and tempdb and the other for the log files.

Disable caching on the volume used for the SQL log drive. This is done on the Azure console and not within the guest. Remember to restart the DB server VM once this is changed.

Do not use geo-redundant storage for any of the SQL drives.

A full list of optimizations for running SQL on Azure is available here: .

Server software

Disk Space

Tachyon Server installation folder is approx. 70 MB.

Tachyon Server logs folder (see Log files) is approx. 210 MB.

For details of SQL database file sizes, please refer to the Server Sizing reference page.

Network interfaces

The following conditions apply to network interfaces, which must be configured before installing Tachyon on a server.

  • One network interface is required for each Switch, with a minimum speed of 1Gbps. Switch interfaces can be on the same or different subnets.
  • An additional network interface is recommended to ensure optimum performance of a Response Stack if it serves more than 500 devices and the TachyonResponses database is on a remote SQL Server. It should have a minimum speed of 1Gbps, or 10Gbps if the Response Stack has 3 or more Switches. Network routing on the Response Stack server must be configured so that SQL traffic is routed over this interface. This interface should not register its IP Address in DNS.
  • An additional network interface is recommended on a DMZ Server, so that an external facing interface is used for incoming response traffic from Tachyon Agents to Switches, and an internal facing interface is used for outgoing response traffic from Switches to the Core on the internal Tachyon Response Stack. The simplest way to ensure the internal interface is used for outgoing response and other traffic is for both interfaces to be on different subnets with no routing between them. All network interfaces on a DMZ Server should have a minimum speed of 1Gbps.

Each network interface must be assigned a static IP Address. Tachyon Setup supports installation using IPv4.

If you have a working IPv6 environment, then please contact 1E for advice on using that.

The table below summarizes the network interface requirements for a Response Stack's database and Switches, where n is the number of Switches on the server up to a maximum of five. For the remote SQL Server requirement, please refer to Preparation: Configuring a persistent route for SQL traffic. However please ensure you also consult your server, firewall and networking teams.

DevicesSwitchesLocal SQLRemote SQL
Up to 50011 x 1Gbps1 x 1Gbps
Up to 50,00011 x 1Gbps1 x 1Gbps (SQL) + 1 x 1Gbps (Switch)
Up to 100,00022 x 1Gbps1 x 1Gbps (SQL) + 2 x 1Gbps (Switches)
Over 100,000n (3 or more, up to 5)n x 1Gbps1 x 10Gbps (SQL) + n x 1Gbps (Switches)

A Background Channel is normally installed on the same server as Switches so that devices can connect to both using the same DNS Name FQDN.


The computername of a Tachyon Server must comply with Microsoft NetBIOS naming standards, which includes having a length of 15 characters or less.

Microsoft's guidance can be found here:

DNS Names

Each server that has Tachyon Server components installed requires its own DNS Name. The Master Stack enables Tachyon users, approvers and administrators to connect to the Tachyon Portal, therefore, it helps users if it has a recognizable and convenient DNS Name such as tachyon.

Tachyon Agents need to connect to Switches and the Background Channel using a DNS Name FQDN defined in the Agent's configuration file. A single-server installation only needs one DNS Name. A Master Stack and Response Stack can only share the same DNS Name if both are installed on the same server. If the server has multiple Switches, and therefore multiple network interfaces, then the same DNS Name can be shared by all Switches, the Background Channel and Master Stack.

The same DNS Name would be used by all the Switches on a Response Stack, but it can also be shared across multiple Response Stacks provided the Name is not also shared with the Master Stack. For this reason, a datacenter serving more than 300000 devices would have two Response Stack servers using the same DNS Name (eg. tachyonrs), and a dedicated Master Stack server using a different DNS Name (eg. tachyon).

A DMZ Server is a special case which needs two DNS Names, an internal DNS Name for the internal network interface, and an external facing DNS Name which may be shared by multiple external facing Switch network interfaces.

Each DNS Name used to access a Tachyon Server must be included as DNS Names in the Subject Alternate Name (SAN) entry of the web server certificate, and the Switch certificate files.

Service Principal Names

Each DNS Name used to access a Tachyon Web Server requires an HTTP class Service Principal Name (SPN) to be registered against the Tachyon Server service account in Active Directory. This allows Tachyon web applications that use Windows Authentication to authenticate clients.

Windows Server roles and features

The following roles, role services and features must be installed/enabled as a minimum.

The Name column is the reference used in PowerShell commands; and for .NET Framework 4.X features the PowerShell name includes 45 instead of the actual version.

Items in bold are included in the PowerShell script available for download from Preparation: Windows Server roles and features.

Tachyon Setup will create a website named Tachyon with the necessary bindings, therefore please do not pre-create a website of the same name.

Role or FeatureDisplay NameNameNotes
Web ServerWeb Server (IIS)Web-Server 
Web Server Common HTTP FeaturesDefault DocumentWeb-Default-DocIncluded in Web-Server.
Directory BrowsingWeb-Dir-BrowsingIncluded in Web-Server.
HTTP ErrorsWeb-Http-ErrorsIncluded in Web-Server.
Static ContentWeb-Static-ContentIncluded in Web-Server.
Web Server Health and DiagnosticsHTTP LoggingWeb-Http-LoggingIncluded in Web-Server.
Web Server PerformanceStatic Content CompressionWeb-Stat-CompressionIncluded in Web-Server.
Dynamic Content CompressionWeb-Dyn-Compression
Web Server SecurityRequest FilteringWeb-FilteringIncluded in Web-Server.
Basic AuthenticationWeb-Basic-AuthOnly required if using 1E ITSM Connect .
IP Address and Domain RestrictionsWeb-IP-SecuritySee note below.
Windows AuthenticationWeb-Windows-Auth 
Web Server Application Development.NET Extensibility 4.XWeb-Net-Ext45Included in Web-Asp-Net45.
ASP.NET 4.XWeb-Asp-Net45 
ISAPI ExtensionsWeb-ISAPI-ExtIncluded in Web-Asp-Net45.
ISAPI FiltersWeb-ISAPI-FilterIncluded in Web-Asp-Net45.
Web Server Management ToolsIIS Management ConsoleWeb-Mgmt-Console
.NET Framework 4.X Features.NET Framework 4.XNet-Framework-45-Core 
ASP.NET 4.XNet-Framework-45-ASPNET

The following roles, role services and features should be removed/disabled.

ParentDisplay NameName
Web Server Common HTTP FeaturesWebDAV PublishingWeb-DAV-Publishing

Switches achieve high speed local communication with the Core by using HTTP instead of HTTPS. For this reason you will see HTTP as well as HTTPS bindings on the Tachyon web site. However, the Core web applications are locked down using IP and Domain Restrictions so that only local processes can access it. The other web applications cannot be accessed using HTTP because their SSL Settings are configured with Require SSL.

The Consumer and Explorer web applications use Tachyon role-based security therefore have Windows Authentication enabled. The other web applications have Anonymous Authentication enabled.

Basic Authentication is required if 1E ITSM Connect for ServiceNow is to be used.

SQL Server requirements

Requirements for SQL Server are covered in other sections on this page:

Active Directory requirements

A Tachyon user can be either a domain account or a security group. 

Access to Tachyon features can be controlled in Tachyon Admin portal Permissions page as follows:

  • Adding individual Active Directory user accounts and assigning to roles. The Admin portal is used to manage these users and their assigned roles.
  • Adding Active Directory security groups and assigning to roles. Group membership is managed in Active Directory. 
  • A combination of the above.

Tachyon is able to operate in a multi-domain, multi-forest environment. If multiple forests are used then ensure trusts are in place that ensure all in-scope user accounts and groups are present in the Global Catalog of the forest in which the Tachyon Server resides. You have a choice of how Tachyon queries Active Directory, specified during installation.

Service accounts

Tachyon Server uses the following accounts for Windows services::

  • 1E Catalog Update Service - domain user account - see below
  • 1E SLA Platform Engine  - Network Service
  • 1E SLA Platform Integrate Agent - Network Service
  • 1E SLA Platform Integrate Manager - Network Service
  • 1E Tachyon Coordinator - Network Service
  • 1E Tachyon Switch Host - Local Service

Tachyon Server uses the following accounts for website application pool identities:

  • CatalogWeb - domain user account - see below
  • SLAPlatform.Admin - NetworkService
  • SLAPlatform.CoreExternal - NetworkService
  • SLAPlatform.Platform- NetworkService
  • Tachyon.Background - NetworkService
  • Tachyon.Consumer - NetworkService
  • Tachyon.Core - NetworkService
  • Tachyon.CoreInternal - NetworkService
  • Tachyon.Portal - NetworkService

The 1E Catalog Update Service account has the following requirements:

  • The account name and its password will be specified in the Tachyon Setup: Configuration for 1E Catalog screen.
  • Must be a domain user account
  • Must have Log on as a service permissions on the 1E Catalog web server (this is granted automatically during installation if the installer account has local admin rights)
  • The installer will create the RoleCatalogUser role in the 1ECatalog database and add the service account to the role. 
  • If a non-defaut install location is specified, then the account or Users localgroup must have the following NTFS security permissions
    • Read permissions to %PROGRAMFILES%\1E
    • Modify permissions to %PROGRAMDATA%\1E

User accounts

All Tachyon users require accounts in Active Directory. AD accounts must have their userPrincipalName (UPN) attribute populated. This is normal, but may be missing if users accounts have been created using scripts.

Tachyon users and approvers should have email addresses to support approval workflow and notifications. Email addresses are mandatory if Two-factor Authentication is enabled.

Users are added to the Tachyon system and assigned roles by a Tachyon Security administrator using the Tachyon Explorer Admin portal.

Please refer to the Users page for an explanation of how to add users to the Tachyon system.

Active Directory Security Groups

Tachyon does not require any Active Directory security groups, however assigning AD security groups to System Roles is strongly recommended, and for any custom roles as explained in the Roles page. This is especially useful for the Server installation account which is a system role that cannot be modified. If the installation account needs additional roles then these can be assigned to an AD security group.

An AD security group is also useful to configure access to the CatalogWeb Admin page, as described in Rebuilding the 1E Catalog.

AD security groups must be Universal, not Global.

AD Distribution groups are not supported.  An AD security group can be configured with an email address. Tachyon will use the email address of an AD security group if it has been configured, and relies on the Mail system to forward emails to the members of the AD security group. If the AD security group does not have an email address then Tachyon will send an email to each member that has an email address.

Active Directory in the cloud

The Tachyon software must be installed on a Windows Server that is part of an Active Directory domain. Companies do not always have their on-premises Active Directory extended into their cloud environment - there are security concerns that must be taken into account and there must be some mechanism for either a secure network connection between the customer's on-premises systems and the cloud environment (usually via VPN connection) or a way of synchronizing the cloud based Active Directory implementation with the on-premises one (through a directory synchronization of some sort).

Both AWS and Azure provide the following 'cloud' based versions of Active Directory:

  1. AWS Directory Service for Microsoft Active Directory (Enterprise Edition) - This is a full implementation of Active Directory, but it requires a VPN and a trust relationship set up with any existing on-premises Active Directory to be able to use on-premises based accounts. This makes it quite a complex solution to implement and maintain. 

    1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.

  2. AWS AD Connector - This is a mechanism for redirecting domain queries from the local network to an on-premises Domain Controller using a VPN instead of needing a domain controller in the cloud.

    1E have not yet tested any Tachyon implementation using this solution and as such it is only supported by 1E on a best-efforts basis.

  3. AWS Simple AD - This is an implementation of Active Directory based upon Samba 4 and provides a limited subset of a full Active Directory. 

    1E do not support Tachyon running in this environment.

  4. Azure Active Directory - Although this provides cloud based identity, it cannot be used for direct active directory connectivity from an Azure virtual machine, for that you need Azure Active Directory Services (next).
  5. Azure Active Directory Services - This provides the ability to domain join Azure Virtual Machines to your Azure Active Directory, however it is not a full AD as you cannot have domain admin or enterprise admin privileges.

    1E do not support Tachyon running in this environment.

The following is the only cloud solution that is fully supported by 1E, and is what we call Extended AD. It doesn't use any of the above, but has the following requirements, which provide an Active Directory presence in the cloud and brings the full capabilities of Active Directory to bear. 

  • Virtual machines located in the customer's cloud network installed with Windows Server as hosts for:
    • Domain Controller(s) in the existing enterprise domain, which can be Read-Only domain controllers (RODC).
    • Other member server(s) which host the Tachyon Server components, including Microsoft SQL Server, must be joined to the same enterprise domain.
  • A permanent site-to-site VPN connection from cloud to the corporate on-premises network.

1E fully support the Extended AD solution for AWS and Azure, which do not change any of the Active Directory requirements described above.

Server Installation Account

This is the account used to run Tachyon Setup (and the MSI installer) when installing or upgrading a Tachyon Server. The account is automatically defined as a Tachyon admin user with limited rights which cannot be edited. If you need this account to have additional Tachyon roles, then you will need to use an AD Security Group instead. The installation account has sufficient rights to add other Tachyon users, assign them to Tachyon roles, including the Permissions Administrator role, which should then be used for ongoing use and management of Tachyon.

Local admin rights

The server installation account has the following requirements on the server.

  • Local admin rights on the Tachyon Server. It must be an Active Directory domain user account that is a direct or indirect member of the Administrators local group on the server where Tachyon Server will be installed.
  • Can be disabled (not deleted) in Active Directory after additional Tachyon admin users have been created in Tachyon, and installation has been verified.

SQL Login for the server installation account

The server installation account requires SQL permissions during installation and upgrade, which can be temporary or permanent. The level of SQL permissions depends on the following:

  • whether or not company policy allows the sysadmin SQL Server role to be granted on the SQL instance(s) that will host the Tachyon Master and Responses databases,
  • whether the databases are created by hand before installation or created by the Tachyon Server installer during installation.
Sysadmin availability on SQL instance(s)SQL Login permissions
sysadmin SQL Server role is permitted

The server installation account requires the sysadmin SQL Server role on the SQL Server instance(s) that host the TachyonMaster and/or TachyonResponses database(s).

This can be used for a new installation, or for an upgrade.

sysadmin SQL Server role is not permitted
The SQL Login permissions required by the server installation account vary depending on which choice is implemented, as described in the following table:

Choice implemented

Role required for the installation account's SQL Login

Database(s) created by the Tachyon Server installer during installation.dbcreator SQL Server role on the SQL instances

Database(s) created before installation - a common scenario if you want to select database location and size.

Also required when upgrading Tachyon.

db_owner database role on the pre-created databases

In addition to the permissions given in the table above, the server installation account also needs ALTER ANY LOGIN Securables permission in order to allow creation of the SQL Login for the Tachyon service account, used by the Tachyon Server web applications and services.

Example scripts are provide below to create a SQL Login and grant roles.

During installation, the Tachyon Server installer will always attempt to grant db_owner permission on each of the Tachyon databases, to the server installation account.

Databases must be configured in multi-user mode.

After installation, the SQL Login for the installation account must retain db_owner role on the databases, and ALTER ANY LOGIN, to support re-configurations and upgrades. If this is considered a security risk, then the server installation account can be disabled after the Tachyon system is operational, and re-enabled when required.

Tachyon user permissions

The server installation account has the following rights as a Tachyon user, configured during installation of the Tachyon Server.

Tachyon service account

Tachyon Server web applications and services use network service account, NT AUTHORITY\NETWORK SERVICE. This version of Tachyon does not support using a domain user account.

SQL Login for the Tachyon service account

The SQL Login that is used by the Tachyon Server web applications and services depends on whether the SQL Server is remote from the Tachyon Server or is local, as described in the following table:

Installation scenarioService account SQL Login
Tachyon Server is remote from SQLThe computer account of the remote Tachyon Server. For example ACME\ACME-TCN01$
Tachyon Server and SQL are localThe local network service account, NT AUTHORITY\NETWORK SERVICE

During installation, the Tachyon Server installer will always attempt to create the SQL Login and grant it db_owner permission on each of the Tachyon databases.

To replace db_owner with lower permissions based on least privilege, please refer to Tachyon Server post-installation tasks: Replace db_owner.

License file

1E will provide you with a Tachyon.lic license file that defines the products and features your Tachyon System is able to use, for how long, and how many devices it supports, this may be an evaluation or subscription license.

  • The license must be activated. Once activated it may be used only by the Tachyon System that activated it.
  • Licences can be renewed or updated, but if allowed to expire then the affected products or features will not be usable.
  • For a new installation the license file must exist in the folder required by the Server Installer.
  • For an existing installation the license file is copied into the folder: %PROGRAMDATA%\1E\Licensing on your Tachyon Server.

For details of what the license file needs to contain, please refer to Design Considerations: License requirements for consumer applications.

If you want to develop your own instructions, or modify downloaded instructions, you will need to contact 1E to add a code signing certificate to your license file, for more details please refer to Code Signing Certificates below.

Whitelisting the 1E license service URL

The Tachyon license must be validated on a regular basis via internet contact with the 1E license service, which needs to be whitelisted in your organization - so that it's accessible during setup and running of Tachyon. The regular validation period is set when the license is requested.

For whitelisting purposes, the Tachyon Server (specifically the Coordinator Workflow module in the Master Stack) requires an Internet connection to the 1E license service, as defined in the license file itself. If activation fails, then the system will install but not be usable until activation is completed.

For guidance on whitelisting and configuring Internet Explorer proxy settings, please refer to Preparation: Whitelisting for license activation and validation.


Public Key Infrastructure

You need to have a PKI in your environment with at least one Issuing CA.

Tachyon requires each Issuing CA has:

  • Certificate Revocation List (CRL) Distribution Point (CDP) that uses HTTP/S 
  • this HTTP/S CDP information is included in certificates issued to Tachyon Server and Agent devices

If you have an existing PKI and have just added a new CDP to support HTTP/S then you will need to re-issue certificates to your servers and devices.

Tachyon deliberately does not work with self-signed certificates for security reasons. Therefore Tachyon Agent or Server cannot be installed on the same server as a Root CA, because its certificate is self-signed.

Tachyon uses TLSv1.2. If your PKI is using SHA512 then please ensure that your environment has relevant updates applied, as described in KB2973337. See Client issues: Enabling SHA-512 to work with TLSv1.2.

If you want Tachyon to manage legacy OSs that Microsoft no longer supports there may be issues with encrypted certificates described in Constraints of Legacy OS.

Tachyon Server Certificates

Each server that has Tachyon Server components installed requires its own Web Server certificate (with the exception of a remote SQL Server). This certificate is also used by the Tachyon Switch, therefore a single-server installation requires only one Web Server certificate. This certificate must be provided prior to installation of Tachyon on the server.

The Web Server certificate requires the minimum of the following:

  1. Issued by a trusted Certificate Authority (CA)
    • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store
    • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store
    • The above CA certificates must exist on the Tachyon Web Server and Windows Agent devices
    • The above CA certificates will be exported and included in the PEM file used by the Switch and any non-Windows Agent devices
  2. Has at least the following Key Usage.
    • Digital signature
    • Key encipherment
  3. Has at least the following Enhanced Key Usages.
    • Server Authentication
  4. Private key must be available.
    • In Microsoft terminology, this means that the certificate allows the private key to be exported. The exported certificate is used by the Switch.
  5. Revocation information is included.
    • References at least one CRL Distribution point that uses HTTP.
  6. The certificate is issued with its fields set to one of the following options. Option 2 is typical.
The default template Web Server available with a Microsoft PKI is suitable for requesting a Tachyon Web Server certificate provided you enable Make private key exportable.

FieldsOption 1Option 2

Subject Common Name Field (subject:commonName)

The DNS Alias FQDN of the server


The hostname FQDN of the server


Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The DNS Alias FQDN of the server


The DNS Alias FQDN of the server


Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The hostname FQDN of the server



The following need to be considered when requesting this type of certificate.

  • The certificate can be used only on the server it was intended, that has the correct hostname FQDN and DNS Alias FQDN.
  • It is not possible use the Create Certificate Request method in IIS Manager Server Certificates, because it does not support all the above requirements.
  • If you have a Microsoft CA, and a suitable Web Server template has been issued and enabled in the Active Directory Enrollment Policy, then it is possible to Request New Certificate in the Certificates (Local Computer) mmc snap-in and use the Certificate Enrollment wizard.
  • Many organizations have their own process for submitting a Certificate Signing Request (CSR). Please ensure all the above requirements are specified. Security administrators sometimes have difficulty providing a certificate with one or more Subject Alternative Names (SAN), and it helps to explain these are type DNS.

If you have a Microsoft CA then it is simplest to use the Certificate Enrollment wizard available in the mmc certificates snap-in, to request a Web Server certificate and fill in the details.

Example certificate request (using Option 2 type certificate)


Tachyon Agent Certificates

Each device requires a certificate with the following properties, in order for the Tachyon Agent to be authenticated by the Tachyon Switch.

  1. Issued by a trusted Certificate Authority (CA)
    • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store
    • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store
    • If the above CA certificates are different to those used by the Tachyon Web Server, they will need to be exported and then
      1. imported on the Tachyon Web Server
      2. included in the PEM file used by the Tachyon Switch
  2. Has at least the following Enhanced Key Usage
    • Client Authentication
  3. Has a private key
    • For a non-Windows device, this must be exportable
  4. Revocation information is included.
    • References at least one CRL Distribution point that uses HTTP.
  5. Has a Subject Name of type Common Name (CN=<hostname>) or Subject Alternative Name (DNS Name=<hostname>) where <hostname> depends on the type of device:
    • On domain-joined Windows PCs this must be the hostname FQDN of the computer, for example W701.ACME.LOCAL
    • On workgroup Windows PCs and non-Windows devices, this must be the hostname of the computer - as returned by the hostname command, for example on Windows PC this could be W701, and on a Mac this could be MAC01.local

The Agent device's certificate is stored differently depending on the type of OS.

  • For Windows devices, the certificate is stored in the Windows Local Computer personal certificates store. 
  • For non-Windows devices, the Tachyon Agent does not use proprietary certificate stores. Instead the Agent requires the certificate exists as a PFX in the Agent installation folder structure (see non-Windows Device Certificate).

If using a Microsoft Enterprise CA then the following should be considered.

  • For domain joined Windows computers:
    • use the Computer template or a duplicate,
    • enable auto-enrollment - so that devices enroll automatically.
  • For workgroup Windows and non-Windows devices:
    • use a duplicate or equivalent of the Computer or Workstation template,
    • the template's Subject Name uses supply in the request - so the hostname can be entered when requesting a certificate,
    • the template must Allow private key to be exported - so a certificate can be requested on a domain joined Windows computer, exported as a PFX and then imported on the target device (see non-Windows Device Certificate).

If using a standalone CA, then certificates must be deployed by other means.

Code Signing Certificates

If you want to develop your own custom Tachyon instructions, or modify those of other authors, then you will need to sign them using your own code signing certificate so that they can be licensed, imported and run in your Tachyon system. You don't need to do this for instructions that are provided with the product or that have been downloaded from the Tachyon Exchange as they've already been code signed and licensed using the Platform and Exchange certificates from 1E.

Ideally all of your Tachyon instruction developers should share a single code signing certificate between them. Each code signing certificate must be registered in your Tachyon license and associated with your organisations instruction name prefix. When you have chosen your prefix and have your code signing certificate(s) you then need to send details of these to 1E, who will update your Tachyon license. This will then automatically activate on your Tachyon Server (assuming it has connection to the Internet).

The following points apply to the importing and running of custom Tachyon instructions:

  • Tachyon will only allow instructions to be imported if they have been signed and the code-signing certificate in the Tachyon Server's Trusted Publishers certificate store exists.
  • Tachyon will only allow instructions to be run if their prefix and code-signing certificate have been registered in the Tachyon Server's license file (even if the instruction has been successfully imported it will be flagged as unlicensed if the license information is not there).

Custom Instructions must be signed by the Tachyon Instruction Management Studio (TIMS) using a code-signing certificate present in the Personal certificate store where TIMS is installed (either local user or machine store). The TIMS user signing the Instruction also needs to have access to the certificate's private key.

For a detailed step-by-step process, please refer to Setting up custom Tachyon Instructions for the first time.

Digital Signing Certificates

Tachyon executables

On Windows computers, the installation MSIs, executables and DLLs of the Tachyon Server and Agent are digitally signed by 1E using the 1E Limited SHA1 and SHA256 signature certificates.

These signing certificates are issued by the Symantec Class 3 SHA256 Code Signing CA, which in turn is issued by the root CA VeriSign Class 3 Public Primary Certification Authority - G5.

For Tachyon 3.2 and later, the SHA1 and SHA256 signature certificates are each countersigned with the same Timestamp signature certificate:

  • Starfield Timestamp Authority - G2, itself issued by Starfield Secure Certificate Authority - G2, in turn issued by the root CA  Starfield Root Certificate Authority – G2.

For Tachyon 3.1, the SHA1 and SHA256 signature certificates are countersigned with different Timestamp signatures:

  • SHA1 - Starfield Services Timestamp Authority - G1, issued by the root CA  Starfield Services Root Certificate Authority
  • SHA256 - Starfield Services Timestamp Authority - G2, issued by the root CA Starfield Root Certificate Authority – G2

The root CA certificates (for signing and countersigning) must exist in the Third-Party Root Certification Authorities store (which is replicated in the Trusted Root Certification Authorities store). These root CA certificates are normally automatically provided by Microsoft's Update Root Certificates feature, however for legacy OS computers in a lab environment that are not connected to the Internet, see Constraints of Legacy OS.

PKI in the Cloud

Tachyon relies on both client (device) and server side certificates to ensure secure communication. In order for these certificates to work the computers need to trust the PKI implementation (issuing Certification Authority and chain of trust). In a standard on-premises environment devices can be enrolled with certificates using Active Directory Group Policy.

It is possible to use a non-Windows based PKI, but it is then left as an exercise for the user as to how to distribute and enrol device certificates to all end-points.

Given the supported Active Directory configuration above, the PKI requirements described above still apply to a cloud based implementation.

Tachyon Web Server certificate

Since clients must be able to access the Tachyon Switch and Background Channel from both the internal corporate network and the Internet, there are some additional considerations when creating the Tachyon web server certificate.

  1. The server must have a consistent external FQDN.

    In AWS a standard EC2 instance has an external FQDN based upon its externally accessible IP address. However, this IP address will change each time the server restarts, and since the Tachyon Switch relies on an HTTPS certificate that utilizes the FQDN to authenticate the server, this would cause the Switch to stop working. In order to work around this, any AWS implementation MUST use an Elastic IP address associated with the network interface of the Switch to ensure that the IP address never changes, and therefore the external FQDN is always the same. Alternatively you can create a CNAME entry in your external DNS to point to the external FQDN of the AWS instance and use the CNAME as the subject name of the server certificate.

  2. The web server certificate must incorporate all DNS Names that will be used to access the server in the certificate SAN.

    Clients can be configured to connect to multiple Switches for resilience and geographic load balancing. In many cases a cloud based virtual machine may be able to be accessed through both an internal VPN network, and an external Internet connection. These connections can be made using the same DNS name (via a CNAME entry as specified in the main documentation) or by different DNS names (where there are separate internal and external DNS domains in use).

    The certificate crafted for the Tachyon Switch  must contain all  DNS Names that will be used to contact the server in the Subject Alternate Name (SAN) entry within the certificate.

Client certificates

Any devices that will connect to the Tachyon implementation must have a client certificate from a PKI infrastructure trusted by the Tachyon server. In a Windows domain environment this is usually provided through an Enterprise Certificate Authority and the use of Group Policy. It is also possible to provide certificates through SCEP, which 1E has tested and support the use of the Microsoft Device Enrollment Service (MDES) for this purpose. Use of other SCEP solutions will be supported on a best-efforts basis.

Email Requirements

SMTP Server

The Tachyon SMTP feature can optionally be enabled to send the following types of emails to Tachyon users.

  • approval request emails to approvers about pending action requests
  • notification emails to users about responses that will expire shortly
  • one-time authentication code emails if the two-factor authentication feature is enabled

Emails are HTML format, without any attachments, and have a typical size of approximately 70KB. You can choose to modify the email banner header.

Emails are sent by the Workflow service and Authentication web application pools, which by default use the built-in Network Service (NT AUTHORITY\NETWORK SERVICE).

If the Tachyon SMTP feature is enabled, your SMTP relay/gateway may require the following to be configured.

  • add the Tachyon Server name or IP address to a new or existing white-list policy
  • disable require SMTP authentication (allow anonymous) - see note below
  • assign the "mail-from" address to an AD account - see Mail-From Address below.
  • if it has a SPF (Sender Policy Framework) or Sender ID policy

In this version of Tachyon, SMTP Authentication is not configurable using the Server installer. The default is anonymous authentication. However, it can be changed post-installation. See Changing the SMTP Host configuration in Tachyon Server post-installation tasks for details of changing the SMTP configuration and disabling email notifications.

Mail-From Address

If the Tachyon SMTP feature is enabled, then a Mail-From address is required as the Sender of Tachyon emails.

Tachyon does not require the Mail-From address to belong to a real AD account or have a real mailbox, however your SMTP relay/gateway might have these requirements, therefore you may need to create an additional AD account.

Choose a suitable email address, especially if there is no mailbox, for example no_reply@acme.local.

Email for Users and Approvers

Tachyon users and approvers require email addresses otherwise they will not receive emails when actions require authentication or approval. Email addresses are mandatory if two-factor authentication is enabled.

If an AD Security Group is assigned rights in Tachyon to approve actions, and the Group has an email address, then Tachyon will use that. However, a group member will receive emails only if your organization's mail system supports group emails and the member has an email address. If the Group does not have an email address, then Tachyon will lookup group members and send emails to any member that has an email address. Irrespective of whether the Group has an email address, members must have emails addresses in order to receive emails.

If your organization uses separate AD accounts for user and administration tasks, then you should consider the impact of using admin accounts for Tachyon if they do not have associated email addresses. 

Two-factor Authentication Requirements

If the 2FA feature is enabled, Tachyon users are prompted to enter a one-time authentication code in addition to their password in order to confirm they want to submit an action instruction. 

The one-time authentication code is sent to the user by email. The two-factor authentication feature requires email.

Feature Dependencies

1E companion products

The following tables show the 1E products that combine to support particular features.


Please refer to the relevant connector page to identify security and other requirements for a specific connector.

Patch Success also requires a Tachyon connector.

Product Packs and Security Roles

Product Packs are the means of installing a pack of instructions. Once the instructions are in Tachyon you need to organize them into Instruction Sets which are used as the basis for assigning custom roles that determine who can do what with the instructions in each Set.

You may want to create AD security groups to assign to custom roles instead of assigning users. You should think about groups of people who will view, question, action and approve packs of instructions.

Export all feature

The Export all feature is available on the responses page for a question once it has finished retrieving all its responses. To enable Tachyon users with the appropriate permissions to use this feature you must ensure that the Microsoft Bulk Copy Program (BCP) is installed on the same server where the Tachyon Core has been installed.

Please refer to Tachyon Server post-installation tasks: Configure the Tachyon Server to support the Export all responses feature for more details on configuring SQL BCP and setting up a suitable share.

Nomad Integration

Nomad integration is available on Windows PC devices and is enabled by default, but can be disabled during installation of the Tachyon Agent.

With the Nomad integration feature enabled, Tachyon Agent will detect if Nomad v6.0.100 or later version is running on the device, and automatically use it to download content from Tachyon Background Channel servers.

Tachyon's use of Nomad works irrespective of whether Nomad is integrated with Configuration Manager or using advanced Nomad features that use ActiveEfficiency.

Configuration Manager is not a prerequisite for Nomad integration with Tachyon, but you will need to consider the following:

Configuration Manager present

You do not need to make any configuration changes to Nomad for it to integrate with Tachyon. Please refer to the Nomad documentation for guidance on designing and deploying Nomad.

Configuration Manager not present

You can deploy Nomad to Windows devices where the Configuration Manager client is not present. You will need to enable the following bits in relevant installer properties:

  • CompatibilityFlags bit 1 - enable long hashes
  • SpecialNetShare bit 13 - enable HTTP(S)

Configuration Manager integration

Tachyon is able to integrate into the Configuration Manager console to provide a right-click context menu that can be invoked from Configuration Manager computer collections. Tachyon can then use the members of the computer collections as the coverage for any Tachyon instruction selected from the menu. The Configuration Manager extensions are part of the Tachyon Toolkit. For more details please refer to Configuring the Tachyon Configuration Manager console extensions.


Agent scripting requirements

Tachyon Agent language SCALE directly supports running PowerShell on Windows and bash on non-Windows devices, which can be scripts that must be downloaded by SCALE when an instruction runs, or actual command text. You will very probably want to use this feature in your own instructions and ones that you download from 1E. Therefore you must ensure the appropriate scripting environment is present on Agent devices.

  • Windows Tachyon Agents can use PowerShell scripts. Ensure your Agent devices have an appropriate version of PowerShell installed to support any custom scripts you may develop. See PowerShell on Windows OS.
  • Non-Windows Tachyon Agents use bash as their scripting medium. This should be present on all non-Windows Tachyon Agent devices.

Firewall Ports

The following are extracts from the Communication Ports reference page.

Tachyon Portal

The table below shows platform requirements for accessing the Tachyon Portal.

Deploying Tachyon Agents

Tachyon Agent Windows Installation Account

Tachyon Agent non-Windows Installation Account


Supported Device Platforms

Requirements for verifying the Tachyon installation

The Verifying page provides detailed steps for verifying a new or upgraded infrastructure, including firsts steps for uploading and running instructions. Below is a list of requirements to perform verification testing.

Constraints of Legacy OS