Skip to main content

Operator FAQ

The Operator FAQ focuses on information decision-makers often ask during their evaluation of the match our solution offers to 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.

Using multiple devices​

Are multiple devices supported?​

Yes. There can be up to 10 authenticators registered for one user.

Your backend needs to be configured to enable enrolling multiple devices and also selecting the one used for an authentication. Contact us for more information.

Will all my devices get a push notification if I try to log in?​

No. Only the device that is selected on the server side will get the push notification. Same for the QR code or mobile-only authentication, the QR code and deep link is only valid for the specific, selected device.

See our REST API on how to specify the device during authentications.

Will the first reaction on one of them win?​

No. There is only one notification sent to the active device, when no device is specified, the default is the one that was added to the account the latest.

Is it possible for Service Desk who have access to Authentication Cloud Management Console to specifically remove one of those devices from the list?​

Yes. Devices can be removed from user profiles from our administration interface.

What happens if I lose my device? How can I get it replaced?​

Old 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 enrolling multiple devices.

From a security perspective, it's important to provide the same level of assurance as during the registration. As otherwise, this can be a weakness in your system.

Registration & Authentication​

Yes. Each for authentication there is a server generated challenge, which is transferred to the device (using Push, QR code or deep link) and then later redeemed by the client talking to the Authentication Cloud directly.

Is there a timeout for an authentication or registration, i.e. the user only has a limited time to react to a request on their device?​

Yes. Each element in the process has a predefined timeout period that ensures that these security credentials are ephemeral.

The configured default timeouts are:

  • Network inactivity: 1 minute
  • Token redemption: 2 minutes
  • User interaction: 3 minutes
  • Overall process: total of 5 minutes

Can these timeouts be configured?​

There are various timeout periods defined for all components and subprocesses. Contact Nevis support to change the defaults.

If during the validity of a challenge the same user starts another login request, will the first request expire immediately?​

Yes. When the application is open, always the latest transaction may be authenticated. If the app is in the background, currently notifications are queued.

If a user uninstalls the app after successfully logging in, are all credentials removed from the device?​

From a practical perspective, yes. Technically, on the devices, the keys remain in the vault and are only removed when the app is reinstalled.

This is a limitation of the secure enclaves provided by iOS and Android.

What happens if the same user re-installs the app? Will they be able to use it right away, or is another onboarding needed?​

As the device does not retain account information, reinstallation means users will need to be reregistered.

How to remove the credential from the Auth Cloud?​

  • Copy the AD B2C User Object ID of the user you want to delete:
AD B2C user profile
  • Delete the user through the API: REST API
  • Alternatively you can delete the user also within the Auth Cloud Management Console
    • Navigate to Instance Overview > Authentication > Users
    • Search for the Object ID that you copied previously. It is used as Username in the Auth Cloud
    • Click Delete and follow the instructions

Data Management & Privacy​

What data is stored, where and for how long?​

For each user, we store:

  • Random, unique user ID
  • Username, to be able to identify users in your systems. This may contain personally identifiable information, and it can be set by you via our API.
  • Metadata such as creation date or update date
  • Registered authenticators: the user's mobile phones that can be used for authentication

For each mobile device, we store:

  • Random, unique device ID
  • Device 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, including make, model, OS and OS version, App and App version

For each transaction procedure, we store:

  • Message to be signed or authenticated is only retained for the duration of the procedure
  • In case of a Push notification: an encrypted context, unreadable by the push messaging systems involved, is sent to Firebase
  • Metadata and Log entries

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 the following services that may also store some of your data. We use Google's Firebase Cloud Messaging service, Cloudflare and Azure for the cloud services. Also note that we are also classed as a GDPR Sub-processor. For more details on how your data may be stored by them, see their respective legal and privacy policies:

Security​

Is there a maximum number of login requests per user per timespan (e.g. per minute)?​

On the server side, currently there is no throttling of authentication requests per user, there is global API throttling to protect the service.

However, we recommend that you implement practical limiting of authentication requests that does not overwhelm the user's device and is in line with your additional flows.

Is there a maximum number of login requests for our Authentication Cloud installation per timespan (e.g. per minute)?​

On the server side, currently there is no global throttling of authentication requests, but there is global API throttling to protect the service.

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 needs to upgrade their Access App before they can use the service again.

Is there additional protection or hardening for the branded Access App?​

Our SDK that the branded Access App uses is hardened with a professional hardening framework.

How is the key material / 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) / Trusted Execution environment (TEE) of the mobile phone and they never leave the device. Neither do the biometrics that are used in the authentication process. We only use low-level functions, and none if this data survives the reinstallation of the Access App.

Multi Environment Setups​

I would like to use my company mobile phone to log into two different environments (TEST and PROD), is that supported?​

Currently the app is configured to dedicated Authentication Cloud instance.

For customers who want to 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?​

Today, that functionality is not yet available, but it's on our roadmap.

Access App & Integrations​

Which mobile platforms do you support?​

Our white-label authentication apps support both iOS (12.4.8 or higher) and Android (6 or higher). The only other notable requirement is that the device must have a trusted execution environment in its hardware.

Can I customize my app?​

Absolutely so. What's more, 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 Auth Cloud to my existing IAM system or my existing user directory?​

Yes, you can. Our processes can be smoothly integrated into existing systems such as Microsoft Active directory or Azure AD B2C.

Can I integrate your functionality into my own app?​

Absolutely. 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.

Further Questions​

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.

Last updated on