Operator FAQ
The Operator FAQ focuses on information that decision-makers often ask when evaluating if our solution matches their authentication needs. Areas include technical questions regarding registration and authentication, security, data management and privacy, multi-environment setups, and the Access App and integrations.
If you are experiencing issues with Authentication Cloud, visit the Troubleshooting page.
If you cannot find the answer to you question, read more in the Access App FAQ, or Request a call back from a Nevis industry specialist.
If you have questions regarding your existing Authentication Cloud instance, log in to our support portal.
Devices
Can a user register multiple authenticators?
Yes. A user can register up to 10 authenticators.
The backend of your application must be configured in a way that enables users to register multiple authenticators and select the one used for an authentication. Contact us for more information.
Does every authenticator of a user get a push notification in an authentication operation?
No. Only the authenticator that is selected on the server side gets the push notification. It is the same for the QR code or mobile-only authentication, the QR code and deep link is only valid for the specific, selected authenticator. When the authenticator is not specified, the most recently added authenticator receives the notification by default.
See our REST API documentation on how to specify the authenticator during authentication operations.
Who can remove a registered authenticator?
A registered authenticator can be removed by users with admin rights to your Authentication Cloud management console. This could be an integrator or a service desk agent.
Can a user replace a lost device and register a new one?
Old authenticators and authenticators on lost devices can be removed and new ones added, but the business logic needs to be created within your existing systems to allow adding, removing, and registering multiple authenticators.
From a security perspective, it is important to provide the same level of assurance as during the registration. Otherwise, this can be a weakness in your system.
Can the Device Ref of the authenticator change?
The Device Ref value held against an authenticator is expected to not change in normal working conditions, and therefore remains unique for the lifetime of the device. However there are exceptions as to when the Device Ref can change on a singular physical device:
- On device factory resets
- When using Android multi-user / multi-profile setups
- When the “App Id / Bundle ID” is changed
Registration and authentication
Is a challenge sent along with a push notifications, QR codes, and deep links?
Yes. For each authentication operation, there is a server-generated challenge that is transferred to the authenticator using push, QR code, or deep link, and then later redeemed by the client talking to the Authentication Cloud directly.
Is there a time limit (timeout) for the user to react to a request in a registration or authentication operation?
Yes. Each element in the process has a predefined timeout limit that ensures that these security credentials are ephemeral.
The configured default timeout limits are as follows:
- Network inactivity: 1 minute
- Token redemption: 2 minutes
- User interaction: 3 minutes
- Overall process: total of 5 minutes
Can I configure the timeout limits?
There are various timeout periods defined for all components and subprocesses. Contact Nevis Support to change the defaults.
If the same user starts another login request during the validity of a challenge, will the first request expire immediately?
Yes. When the application is open, only the latest transaction can be authenticated. If the app is in the background, notifications are queued.
If a user uninstalls the app after successfully logging in, are all credentials removed from the authenticator?
The keys remain in the vault on the devices, and are only removed when the app is re-installed.
This is a limitation of the secure enclaves provided by iOS and Android.
What happens if the same user re-installs the app?
As the authenticator does not retain account information, users need to be re-registered after re-installing the app.
How can I remove Azure AD B2C credentials from the Authentication Cloud?
- Copy the AD B2C User Object ID of the user you want to delete:
Delete the user either through the REST API, or within the Management Console through the following steps:
- Navigate to Users.
- Search for the Object ID that you copied previously. It is used as username in the Authentication Cloud.
- Click Delete and follow the instructions.
Data Management and Privacy
What data is stored, where and for how long?
For each user, we store the following data:
- Random, unique user ID.
- Username, for identifying users in your systems. This may contain personally identifiable information. You can set the username through our REST API.
- Metadata, such as creation date or update date.
- Registered authenticators, that is, the user devices, such as mobile phones, that can be used for authentication.
For each mobile device, we store the following data:
- Random, unique authenticator ID.
- Authenticator name, so the end-user can identify their device. This may contain personally identifiable information as the name can be defined by the end-user.
- Device metadata, such as make, model, OS and OS version, App and App version.
For each transaction procedure, we store the following data:
- An encrypted context that is sent to Google Firebase. This is only applicable for push notifications, and the data is unreadable by the push messaging systems involved.
- Metadata and log entries.
In a transaction prodedure, a message to be signed or authenticated is only retained for the duration of the procedure.
Logs are not retained for more than 180 days.
Database backups are not retained longer than 60 days.
For other general Nevis related questions, see our legal pages.
Which sub-processors are used and what data do they store?
We rely on various services that may also store some of your data. We use Google Firebase Cloud Messaging service, Cloudflare and Azure for the cloud services. Note that we are also classed as a GDPR Sub-processor. For more details on how your data may be stored, see their respective legal and privacy policies:
Security
Is the number of login request per user per time span limited?
On the server side, currently there is no throttling of authentication requests per user, but there is global API throttling to protect the service.
However, we recommend that you implement practical limiting of authentication requests in line with your additional flows, to avoid overwhelming user authenticators.
Is the number of login requests for our Authentication Cloud instance per time span limited?
On the server side, currently there is no global throttling of authentication requests, but there is global API throttling to protect the service.
Can I limit the number of authentication requests sent to an authenticator?
Yes. For SMS and push authentication, we have implemented rate limiting. This mean that you can set a limit for the number of SMSes or push notifications sent to authenticators within a time frame. SMS rate limiting is always enabled, push rate limiting is an optional feature that can be enabled or disabled. For more information, see SMS rate limiting and Push rate limiting.
How does “Forced App Upgrade” Work?
Whenever the Access App is started, it checks the version of the app that is available in the app store. If the installed app has a lower version, the app store is opened and the user must upgrade their Access App before they can use the service again.
Does the branded Access App have additional protection or hardening?
Our SDK that the branded Access App uses is hardened with a professional hardening framework.
How is the key material or biometrics protected on the device?
All the private keys that are used in the FIDO processes are stored and used in the Trusted Platform Module (TPM) or Trusted Execution environment (TEE) of the mobile phone. Private keys and biometrics used in the authentication process never leave the device, with the exception of passkeys. Passkeys are synced to a cloud service, such Apple iCloud Keychain or Google Password manager, and the syncing is end-to-end encrypted. Authentication Cloud only use low-level functions, and none of this data survives the reinstallation of the Access App.
How are the logs and reports functions protected from code injection?
We implemented an escaping solution for all CSV exports within Authentication Cloud. This means that upon CSV generation, escaping characters are added to all logs and reports API responses to eliminate the vulnerability to code injection. Specifically:
- All populated string value fields and date fields are encapsulated in double quotation marks.
- All populated string value fields also get a single quotation mark before the first double quotation mark.
Purely numeric fields are not escaped, to keep their usability with Excel numeric functions. See Log export example http response for an example log API response.
Multi-environment setups
Can I use my mobile phone to log into two different environments?
Currently the app is configured to a dedicated Authentication Cloud instance.
For customers who want a strict separation, we recommend ordering a secondary Authentication Cloud instance for their testing.
Can I switch profiles within the Access App, or does the app automatically detect the right one?
The Access App is currently only able to support a singular profile and backend, in a future release multiple, backends and profiles are planned to be supported.
Access App and integrations
Which mobile platforms are supported?
Our white-label authentication apps support both iOS (12.4.8 or higher) and Android (7.1.1 or higher). The only other notable requirement is that the device must have a trusted execution environment in its hardware.
Can I customize my Access App?
Yes. We have integrated Figma into our process, so your design team can use the most widely used industry tool to customize the look and feel of your authentication app. For more information, see Customize the Access App.
Can I connect Authentication Cloud to my existing IAM system or my existing user directory?
Yes. Our processes can be smoothly integrated into existing systems such as Microsoft Active directory or Azure AD B2C. For more information, see Azure AD B2C integration.
Can I integrate Authentication Cloud functions into my own app?
Yes. Many of our customers do. You can use our SDK to build secure authentication functionality into your existing mobile app. The Nevis Mobile Authentication Client SDK has extensive documentation available to help you with the design and implementation of the required use-cases and workflows. For more information, see the Mobile Authentication SDK documentation.