Skip navigation
All Places > Products > RSA SecurID Access > Blog

RSA SecurID Access supports using FIDO-certified security keys as an authentication optionRSA SecurID Access supports FIDO2 and U2F compliant security keys.


RSA SecurID Access supports security keys for both primary (the passwordless user experience) and additional authentication (additional or step-up authentication). FIDO2 security keys can be used for primary authentication and additional authentication . U2F security keys can be used for additional authentication. Primary authentication is only supported for service providers (SAML applications). See FIDO Token.


Perform these steps to start using security keys with RSA SecurID Access. These steps assume that you have an existing RSA SecurID Access Cloud Authentication Service deployment.


  1. Set up FIDO Token as an authentication method on the Cloud Administration Console. 
    1. Confirm that FIDO Token is in the assurance level that you want. See Configure Assurance Levels.
    2. Confirm that you have an access policy that uses that assurance level. See Add an Access Policy.
    3. Determine if you want to use FIDO Token for primary authentication or additional authentication, or both. If you want to use FIDO for primary authentication, add a service provider and specify FIDO as the primary authentication method. See Add a Service Provider
    4. Update the My Page settings, so that FIDO Token registration is required through My Page. See Manage RSA SecurID Access My Page.
    5. Review the system requirements for FIDO Token. See FIDO Token Requirements.
  2. Register your security key in My Page. If FIDO registration is not enabled through My Page, FIDO Token can be registered during additional authentication using in-line registration process. See different ways you can Restrict Access to My Page.
  3. Authenticate to your service provider to see it work. See Passwordless experience using FIDO2 Token for more details and demo.
  4. Confirm your test authentication in the User Event Monitor. See Monitor User Events in the Cloud Administration Console.

Passwords suck

No one likes passwords, and they are the weakest link in the security chain. End users have way too many passwords to manage and they are impossible to remember— especially when you are required to change them every few weeks. 80% of breaches still involve compromised and weak credentials1. Passwords are expensive for administrators and help desk, as difficult passwords get forgotten frequently and results in higher administrative and help desk costs. In 2018, security breaches costed companies an average of $3.86 million per breach². For CISOs, they are the leading cause of breach-related nightmares. End users and administrators can easily fall into the trap of phishing attacks, resulting in access to systems or database breaches and exposing critical customer and organizational information to adversaries.


Passwordless is not new to RSA

Do you know that RSA has been providing passwordless experience to our customers? Yes, for last 35 years our customers have been using RSA SecurID Tokens for securing their VPN, firewall, Unix servers and much more without requiring passwords -- a passwordless experience. Building on this, now end users can also use FIDO2 authenticators for passwordless authentication experience when accessing Web/SaaS applications (acting as SAML Service Provider) and using RSA Cloud Authentication Service as Identity Provider (IdP).


FIDO as a strong authentication method

For starters, the FIDO protocol, part of FIDO Alliance, uses standard asymmetric cryptographic techniques to provide stronger authentication which offers a much better phishing resistant alternative to passwords. During the FIDO device registration process, a user’s device creates a public/private key pair and registers its public key with the online FIDO service. Authentication is done by the client device proving possession of the private key to the service by signing a challenge sent by the service. In FIDO2, the client’s private key can be used only after the user unlocks the FIDO device using secure action such as PIN or Bio-metrics. Many of the Hardware FIDO2 authenticator vendors offer tokens that can be setup to use PIN or have a built-in fingerprint reader on the device to secure the private key. Many of the Software FIDO2 Authenticators built into platforms (e.g. Google’s Android 7+ mobile platform or Microsoft Windows 10 1903 patch) can also secure the token using Face Id (or other methods) for user verification, if supported by the device they are running on.


If you are wondering how FIDO2 is considered a strong authenticator and a better phishing resistant alternative, reason is that it supports MFA by providing two of the three authentication factors required to meet NIST 800-63-3 AAL2 security requirements – Know something (PIN) OR Are something (Biometrics) AND Have something (asymmetric cryptography based FIDO2 Token).


FIDO Token enrollment and self-service at scale

While FIDO2 protocol requires need for user verification and uses asymmetric cryptography for strong authentication, it does not talk much about life cycle management of the FIDO token itself from end user’s point of view and leaves it to the security vendors offering FIDO2 as an authentication service. RSA strongly believes that using FIDO at scale within the enterprise requires far more than just adopting a new authentication protocol. Managing the entire lifecycle of FIDO tokens at scale plays an important role in the success of its adoption within an enterprise. As an example, it requires making the enrollment process of these devices convenient by offering secure self-service capabilities at scale and also support device replacement in case current device is lost. These are some of the key FIDO token life cycle management aspects which cannot be ignored and need to be taken care at scale within an enterprise.


RSA SecurID Access and FIDO Support

RSA is a board member of the FIDO Alliance and has been driving the enterprise security workstream. RSA SecurID Access has been supporting FIDO devices for many years as an additional authentication method, and now we are extending that support to use FIDO2 authenticators as a primary authentication (2FA/MFA) method replacing password to access SaaS or Web Applications (service providers).


 As part of RSA SecurID Access, both FIDO and FIDO2 devices can be managed using the enterprise grade RSA self-service portal My Page. In case users lose their FIDO devices, they can go to My Page and delete the existing device and register a new FIDO device. If these FIDO authenticators are used as step-up authentication, they can also be registered in-line during step-up authentication flow itself.

Let us discuss below the end-user experience of using FIDO2 Token to securely access SaaS/Web applications followed by administrative workflow of managing the FIDO2 authenticator using RSA SecurID Access.


End-User experience using FIDO2 Token

Enterprises are looking to provide friction less user experience to their modern work force who needs to access business applications from anywhere and anytime. Passwords being prone to phishing attacks and hard to manage, customers can now offer FIDO2 Tokens to their end users to gain access to business-critical applications. Now users accessing SaaS Business Applications like (Salesforce) can use FIDO2 Token to securely authenticate and get access these applications without requiring password.


Click on this demo to see how RSA SecurID Access allows a user (a sales person in this example) to use FIDO2 Token to authenticate their identity and get access to their Salesforce account after validation.


Demo 1: Passwordless Authentication using FIDO2 Token


Understand the steps involved in authenticating using FIDO2 Token

Let us briefly talk about the authentication flow using FIDO2 Token shown in the demo. In this use case Administrator has configured a service provider (e.g. Salesforce) to require FIDO2 Token for passwordless authentication and end-user already has a registered a FIDO2 Token to use.



  1. User tries to access Salesforce (SP) and chooses RSA SecurID Access as an Identity Provider (IdP) to authenticate. User is redirected to IdP (CAS). SP and IdP are communicating over SAML.
  2. User enters their email address and CAS checks the access policy for this user and finds that FIDO2 Token is required as primary authentication method.
  3. CAS challenges the user to authenticate using FIDO2 Token. User presents FIDO2 Token to authenticate and uses PIN or Biometric for user verification. Note that this is a passwordless authentication flow.
  4. CAS (FIDO Servers) authenticates the user and communicates to SP using SAML about the successful auth.
  5. SP (Salesforce) allows user to access their account after successful authentication.


End-User experience enrolling FIDO token at scale

1. RSA SecurID Access self-service portal, My Page, to manage FIDO Token

Users can register their FIDO Tokens by using, self-service portal, My Page. This portal also allows users to manage their registered mobile devices along with FIDO tokens. Users can delete an existing mobile devices or FIDO Tokens and re-register new ones in case they lose their current devices using this self-service portal.


Demo 2: Registering FIDO Token using My Page



2. In-line registration of FIDO Token as part of Authentication work flow

In the case where FIDO authenticators are used for additional authentication (not the primary or first factor), new tokens can be registered during the authentication work flow itself. This is not allowed if the FIDO2 token is used for primary authentication. The user must first register it using My Page, as mentioned above.


Admin experience enabling FIDO2 Token Authentication for Service Providers

First, an administrator configures a service provider (SaaS or Web application like Salesforce) in the Cloud Administration console and chooses the authentication option RSA SecurID Access manages all authentication and FIDO Token as primary authentication.  



With the above steps, an administrator is configuring the service provider to require FIDO Token for primary authentication, without requiring any password. As mentioned earlier, this  has to be a FIDO2 Token as it supports user verification. Optionally, an admin can configure additional authentication methods for higher security, if needed. Also, policy-driven conditional attributes and identity assurance in RSA SecurID Access can be added as part of further securing access to service providers.


Admin experience setting up self-service portal, My Page

Administrators, through the Cloud Administration Console, can control if users are allowed to manage their mobile devices or FIDO tokens using My Page. This is where they enable self-service portal for users and manage their mobile devices and FIDO Tokens. Administrators can achieve a higher assurance level by creating a custom access policy using MFA so that users can securely access My page. Optionally, conditional attributes and identity assurance can be added as part of securing My Page for FIDO Token registration


In case My Page is enabled for users to manager FIDO Tokens, inline registration will be disabled automatically



FIDO2 is a great step forward, enabling passwordless access to business-critical resources and mitigating phishing attacks. RSA is proud to be leading this effort and helping our customers take passwordless journey for on-prem applications as well as SaaS applications and enabling secure and convenient life cycle management of FIDO Tokens.


Verizon Data Breach Investigations Report (DBIR)

2018 Cost of Data Breach Study, Ponemon Institute Research Report

Today RSA announced it has completed an integration on Amazon Web Services (AWS) that will tie Session Tags with identity context through RSA SecurID Access.


This integration takes advantage of the benefits of Session Tags (more on this shortly) and the strengths of RSA SecurID Access, an industry-leading and award-winning multifactor authentication and identity assurance solution. RSA customers can now extend the value of key identity context that they already leverage within the product and further enhance the security of their AWS resources. Combined with the RSA SecurID Access flexible deployment (SaaS, cloud, on-premises, or hybrid), choice of authentication methods (mobile push notifications, one-time passwords, fingerprint/facial biometrics, SMS, voice recognition, FIDO and hardware and software tokens), and dynamic, risk-driven access policies – this integration simplifies intelligent identity access and assurance decisions.


For the uninitiated, Session Tags enable AWS users to categorize resources and associate them with critical business aspects, such as purpose, environment or owner. In a world of dynamic hybrid cloud environments and workload management, maintaining these connections can be complex or expose users of these systems to risk.


As noted, one of the primary parameters for categorization is owner, i.e., who is responsible for maintaining this resource. As our IT boundaries continue to break down, the ability to leverage identity as the basis of ensuring data and resource confidentiality, integrity and availability becomes a critical link in enabling secure cloud strategy.


Typically, the only information IAM or security teams have about a user when authenticating to AWS is their username. This piece of information alone is insufficient for an organization to truly understand what that user should have access to. How would a downstream system (in this case, AWS) evaluate the login event and determine whether access to an environment should be allowed? Additional user context added by RSA SecurID Access as Session Tags can help address this gap.


Additional context (tags) that RSA SecurID Access could also provide beyond user ID could include: displayName, emailAddress, title, organization, department, manager, and officeLocation.  Given this additional context, appropriate permissions could be applied to session. A customer can create many more of these tags using RSA SecurID Access.


All of this additional context could be passed in the form of Session Tags and then appropriate permissions applied based on a user’s department, manager, or some other attributes. This attribute-based access control (ABAC) mechanism enables intelligent decisions to be made downstream by either a human or a machine to support decisions based on business context, i.e. permissions rules in AWS IAM.


As part of our growing collaboration with AWS, we’re excited about this integration as another step in advancing customers’ ability to manage new digital risks as they transform IT through opportunities such as cloud computing.


Current RSA SecurID customers interested in leveraging this new integration can learn more here.

  • Password-less authentication experience for users accessing SaaS/web applications using FIDO2 Token as primary authentication method

RSA SecurID Access has provided password-less experience to its customers for the last 35 years by offering strong authentication using RSA SecurID Tokens for use cases with VPN, firewall, Unix servers, and more. Building on this, now end users can also use FIDO2 authenticators for password-less authentication experience (in addition to RSA SecurID Token) when accessing Web/SaaS applications, which are acting as SAML Service Provider (SP) and using Cloud Authentication Service as Identity Provider (IdP). The FIDO2 authenticators can be securely enrolled using RSA SecurID Access self-service portal, My Page or using in-line registration process when used for additional authentication. Policy-driven authentication can leverage location or IP address based conditional attributes along with machine learning driven identity assurance for improved security.  


  • Ensure uninterrupted user access to SaaS/Web apps with new cloud-native emergency access 

Organizations now have two options for emergency access. For Cloud Authentication Service and RSA Authentication Manager deployments, Authentication Manager provides a universal option for emergency access.  Cloud-only deployments now have native emergency access capabilities that can be enabled for end users accessing SaaS or Web applications.  End users who have lost or misplaced their authentication devices can contact the Help Desk, and the help desk administrator can provide emergency access codes that can be used for a specific time period by this useraddi.  Emergency access can be configured as an available authentication method and can be enabled for users even if the RSA SecurID Authenticate app isn't enrolled. This allows greater flexibility, especially in the case where user forgets their FIDO authenticator, which is used for additional authentication.


  • Improved productivity and security for Windows sign-in experience with new release of RSA MFA Agent 1.2 for Microsoft Windows


RSA MFA Agent 1.2 for Microsoft Windows leverages the RSA SecurID Access Cloud Authentication Services to provide strong multifactor authentication to users signing into Windows machines, both online and offline. This MFA Agent now provides more authentication choices for users, along with features that improve user productivity and security during Windows sign-in. End users can also have uninterrupted access to their Windows machine in case they have temporarily forgotten or misplaced their MFA authenticators (for example, an RSA SecurID Authenticate device or an RSA SecurID hardware token). For more information, see


  • Corporate re-branding using company logo for the end-user authentication experience

Organizations want to provide a consistent branding experience for their end users during the Cloud Authentication Service additional authentication. Now organizations can display their company logo during the additional authentication flow. Administrators add this logo in the Cloud Administration Console.


  • Improved SaaS resiliency and availability

A critical component of the Cloud Authentication Service internal messaging infrastructure, responsible for all communication between components, has been replaced. A more reliable secure connector cloud REST implementation has been implemented and will solidify performance and reliability.


  • One employee, one Authenticate app for all accounts

To help improve security, IT admins typically separate administrator and user accounts for the same employee. This is widely regarded as a security best practice because it adds another hurdle for an attacker trying to gain a foothold into the IT infrastructure. However, this meant that these same employees must have separate registered devices running the RSA SecurID Authenticate app per account. Now, with the release of the RSA SecurID Authenticate 3.1 for Android and iOS and a corresponding upcoming release for Windows, these users will no longer need to have separate devices. Users can now conveniently register all their accounts within the same registered app by adding them as they would normally do.


  • Share identity risk context with third-party party SIEM platform providers for better threat analysis 

Security operations center (SOC) analysts prefer to have as much identity context as possible during threat analysis to get a 360° view of the incident. RSA SecurID Access can now share such identity context in a more granular way to any SIEM platform. Specifically, customers can now get overall identity confidence scores along with the categories (device, behavior, and location) that influenced or contributed to the overall score. The risk or confidence score are now exposed securely through the Cloud Administration User Event Log API. Through the API, customers can now export user risk information to any Security Information and Event Management (SIEM) platform for further analysis.  This will enable SOC analysts to have better identity context in building Indicators of Compromise (IoCs) and preventing identity specific attacks.


RSA continues to strengthen its RSA SecurID Access Cloud Authentication Service with the September and October product release.  For further details on all the new and updated capabilities of the this release, please refer to the Release Notes.

An RSA Cloud Authentication Service (CAS) customer asks the following:

"Is there a way to lock the self service portal (CAS My Page) down to just our public IP address range?"

The short answer is yes.


UPDATED: 11/22/2019 with information on FIDO.


Because the Cloud Authentication Service and it's associated My Page are cloud tenanted services, initial access is allowed to CAS login pages (Admin and My Page) from anywhere. This would be the same as anyone being able to access Amazon, Microsoft or Google logins from anywhere. The ability to restrict users from moving forward in the My Page self-registration process, as with leveraging AWS, Azure or GCP functions, is based on strengthening access to these services using CAS administrative options.


A Review of Customer Options for Securing the My Page Self-Registration Experience


To review, customers may strengthen access to the My Page self-service registration experience in the following ways:


1. Restrict By Password Plus Policy


When setting up the My Page service, a policy for access to the page must be selected. This policy can be written to take into account a number of items when granting access to the page. Additional step-up can be required. For premium customers, HTML5 geo-fencing is available as well as Trusted Networks in order to network restrict authentication attempts.


In the case of "chicken and egg" new user scenarios where step-up authentication may still be desired, premium customers have the option of requiring MFA for Authenticate app token registration or FIDO token registration through SMS or Voice on-demand authentication (ODA), selected by policy. The identity source linked to My Page 

authentications must, in these cases, have a user's mobile device number registered in the identity source and that mobile device number sync'd into the CAS.


Trusted Networks is a premium option that allows customers to deny authentications attempts by users who attempt to register from outside of a trusted network location. I will describe this in detail after a brief review of the other two remaining options for further locking down and protecting the My Page self-registration experience.


2. Restrict By SecurID


Customers with existing hard/soft tokens (supported by the Authentication Manager) can select "SecurID" to use SecurID tokens to 2FA protect the My Page registration and then register FIDO tokens and/or the Authenticate app to move from a soft/hard token experience to a more modern MFA experience on the Authenticate app.


This is done simply by selecting "SecurID" as the authentication option under Authentication on the My Page configuration page.


3. Restrict By FIDO Token


Customers with registered FIDO tokens can select "FIDO" to use FIDO tokens to further protect My Page access.


This is done simply by selecting "FIDO Token" as the authentication option under Authentication on the My Page configuration page.


4. Restrict Through Use of an Alternate Cloud IdP


Using this option, customers may leverage another existing cloud IdP for seamless authN into the My Page registration experience.


This is done by selecting "Performed by Cloud Identity Provider," and selecting a Cloud Identity Provider from the adjacent drop down, or by clicking "Add Cloud Identity Provider" to add a cloud identity provider. (The details for adding an external cloud identity provider are out of scope for this discussion. For information on adding an external Cloud Identity Provider to the CAS, click here.)


For further documentation on securing the CAS My Page Self-Service Registration experience, please click here.


Denying CAS My Page Access to Users Outside of Trusted Networks


Let's go back now and demonstrate how a customer would deny authentication to users attempting to self-register from network locations outside of an established, trusted network.


1. Add Your Trusted Networks


First, we need to build our trusted networks from which we will accept My Page authentication attempts. Any attempts from outside of these trusted networks will be summarily denied by policy, regardless.


1A. Log into the CAS Administration Console:


Enter the administrative credentials you were provided or that you have subsequently created to login to the CAS Administration Console and Sign In.


1B. Go to the Trusted Networks page to add your trusted network(s):



Click "Add" to add any trusted networks from which you would like to allow authentication attempts. Any authentication attempts from outside of these networks will be denied by policy, regardless. Here, I have already added a hypothetical trusted network called "Home" with a hypothetical single external address.


Addresses are added using CIDR notation with address and network mask to allow for blocks of IPs to be added quickly and easily.


Click Save to save the Trusted Networks that were added/created.


2. Build A Location-Specific Policy


Next, we need to build a location-specific policy that will deny logins to users who attempt to register from outside of the trusted network we have designated previously above.


(Consider: Any user from anywhere will still be able to reach the My Page login page. But attempts to login from outside of a trusted network will be denied, even if valid credentials are entered. The denial of the login provides the user making the attempt with no clue as to whether the credentials themselves are correct or not. All logins, valid or not, will be denied out of hand if attempted outside of the trusted network we have established.)



2A. Go to the Policies page to add a new policy:



2B. Click "Add A Policy".



2C. Complete The Policy Wizard.

  • Name the policy (example: "Network-Restricted My Page Access")
  • Give the policy a good description (optional) (example: "Deny My Page logins from locations outside of trusted networks")
  • Select the identity sources you wish to include in the policy (this will determine which users, if they fall into the trusted network locations at login, will be able to successfully authenticate).
  • Build the policy rule/ruleset (I will expand explanations at that point).


Here we pick a good, descriptive name such as "Network-Restricted My Page Access." You can enter any name and description that best suits you.


Here we select the identity source from which we will accept and validate authentications to the My Page page. In this case, I have selected my own Demo AD sitting on-prem. Any available source your organization has will work fine.


In this example, we will use any user from the previously selected identity source (eg. my Demo AD). If you would like to further restrict which users may authentication to My Page, you may select "Selected Users" under Target Population, and apply additional conditions for selecting groups of users specific to this policy.


Our access will be selected as "Conditional" because we will be basing access on trusted network locations in the next few steps.

Under Access Details and "Conditional", click the "Add" button to begin adding the conditional access.


In the dialog that results from clicking "Add," choose "Trusted Network" and "True" under Attributes. Choose "Allow Access" under Action. Click Save.


Now our Access Details for the policy rule should look like this:



The rule now reads as follows:


"For all the users in the selected identity source, use conditional access for this policy. That conditional access will be: (a) for users inside of a trusted network, we will validate primary authentication and allow access if primary authentication from the identity source is valid. (b) For users outside of the trusted network, we will deny access, regardless."


Click Save and Finish to save the new policy that restricts authentications based on Trusted Networks.


3. Apply Our Network-Restricted My Page Access Policy


Now we just need to apply this policy to the My Page configuration, and we will achieve our goal of restricting authentication attempts to users authenticating only from trusted networks.


3A. Go to the My Page Configuration Page.



3B. Select The Network-Restricted Policy Previously Built.


Our intended method of allowing authentication to the My Page self-registration experience is through (a) primary authentication against our selected identity source, (b) restricted to trusted networks only. Any authentication attempts that either fail primary authentication or take place outside of the trusted network will be denied.


So we want to choose "Password" as the Primary Authentication Method under Authentication. And the policy we built as the Access Policy for Additional Authentication.


After selecting the policy we built to restrict authentications to our trusted networks, click Save above.


4. Publish Our Changes


As always whenever we make changes in the CAS Administration Console, we need to publish our changes to make them live.



Let's Review!


In this article, we learned:

  • Like any public cloud offering, login pages to RSA Cloud Authentication Service can be accessed from any location, by any user on the internet.
  • We can strengthen access to the RSA Cloud Authentication Service My Page self-registration experience using a number of options, available administratively to customers of CAS.
  • All options for strengthening My Page authentications were briefly reviewed.
  • A specific cookbook recipe was shared for restricting My Page authentications to only networks we trust using three building blocks:
    • Trusted Networks (available to Premium customers)
    • A specific, network-restricted policy (that included Trusted Networks)
    • Application of our network-restricted policy to the My Page configuration page

This blog started as a knowledge base, KB article, but it was quickly decided by the KCS content review team that any put in this KB would be added to, and possibly changed.  It is our hope that all growth here will be useful.


While RSA does not have a Best Practices Guide for Authentication Manager, we do have planning, performance and configuration guides.  See    RSA Authentication Manager 8.4 Performance & Scalability Guides   See Also

RSA Authentication Manager Previous Versions page for versions earlier than 8.4.



  1. Probably the single best piece of advice I ever got in the technical business world is that "you tend to get more credit for a small success than a big failure."  So good principles are to watch scope creep, keep jobs manageable and then use manageable subprocesses as building blocks for larger processes or jobs.
  2. Try to stay up to date with versions and patches.  Not only are new features are included in newer versions, but bug and vulnerability fixes are always targeted for the latest releases.  Be aware that your support contract mandates staying current with versions, and that asking RSA apply new fixes to older versions results in exponentially more complex Quality Engineering test scenarios, especially in the area of upgrades or updates.  Applying a hot fix to an older version of AM means QE has to go back and test previous version updates.
  3. Authentication is the act of verifying the authenticity of someone or something; in other words, to make sure someone is who they claim to be.  Authentication is the foundation of all access control, and all access controls are only as sound as the authentication system under girding them.  Authentication Manager two factor authentication (2FA) is the integration of something you have (the tokencode) and something you know (the PIN) into the passcode.
  4. If your tokens do not require PINs (that is, PINless tokens), then you do not have 2FA configured. and have an inherently less secure authentication mechanism.
  5. If you mate PINless tokens with passwords, you have a multi-factor authentication (MFA), which may or may not be a strong as 2FA, depending on the degree of integration and the protection of token seeds.  What I'm saying is there is a debate, which we will not resolve here, and all I can say is this debate revolves around the concept that one eight-foot high fence is considered more secure than two four-foot high fences.  Your risk analysis needs to determine if your MFA is sufficient to mitigate your risk concerns in according to your business principles.

Technical Principles

  1. You cannot extend the size of the RSA Authentication Manager appliance disk drive on a virtual machine after it has been deployed.  To resolve this, you will need to deploy a new instance, probably a replica that you will promote.
  2. Authentication Manager is an authentication system first, and only secondarily a reporting system; therefore you need to understand several database concepts, such as managing log archival maintenance, which lets you understand how long authentication and administration data is maintained in the database for your authentication and administration reports.
  3. Log archival management is closely related to database management.  As authentication and administrative activity is logged into or added to the database, the database grows in size. As this information grows older there is a point where is should be archived out and purged from the database, so that the database does not grow infinitely.  However, most databases do not automatically compress the space allocated to this information as it is archived, so the database does not instantaneously shrink, instead the database marks this space as writeable so newer logged data can use this space, so that the rate of growth of the database is slowed.  If you want or need to compress the the Authentication Manager internal database, you need to run the postgres vacuumdb utility.  For information on how to run this utility, please contact customer support and open a case.  Cite article 000035033.
  4. If your Authentication Manager primary runs on VMware you may have deployed this server with the default disk size of 100GB.  If you also have thousands of users, there may be circumstances where due to logging and archiving your disk could be at risk for filling up.  Therefore, it is wise to configure a Critical System Event Notification in the Security Console (Setup > System Setup), and enable an email for Low disk space events.  Optionally modify the warning threshold from the default setting of 5GB to something larger to give you an earlier warning.  See 000036191 - How to modify the low disk space critical event email warning threshold from 5 GB to 10 GB free in RSA Authentication Manager 8.2.1 and higher for more information.

Recommended KBs

Server consoles

Agent and Authentication Knowledge

Linux and certificate knowledge

Authentication Manager Integration Service (AMIS) articles

Hardware appliance knowledge

Over a year ago, RSA proudly launched the RSA SecurID Access My Page user self-service portal. It is our cloud-hosted self-service portal designed to help users easily register and conveniently manage their own authentication devices without any help from the IT Help Desk. However, ease and convenience does not equate to reduction in security. Utilizing our experience implementing user self-service features, we want to make sure that users do not end up being the weakest link. That is the vision for My Page, a place where users can securely register and manage their own authentication devices. This makes for Happy Users, and Even Happier Administrators.


Continue reading to find out how this is done in the RSA SecurID Access August 2019 Cloud Authentication Service Release. 


Improvements and Additional Configuration Options for My Page


The goal of an application portal is to provide users with a centralized place to access the applications needed on a daily basis, while at the same time allowing admins to control which applications users can access. This boosts user productivity when using multiple applications daily and increases security by governing the use of corporate applications. 


Customers now have the flexibility to provide access to RSA SecurID Access My Page through third-party application portals of their choice including the RSA SecurID Access Application portal. This makes it even easier for users to find My Page when managing their own authentication devices.   


Additional My Page options are now available, such as setting the destination page users go to after signing out of My Page or when they encounter an error. This allows users to stay within the same corporate virtual environment after managing their devices and to easily get help when needed.



Improved Single Sign-On Option When Adding a Service Provider


One way to promote usability and ease of use is to ensure a consistent look and feel across applications deployed within the organization. This is especially important for basic tasks such as user authentication required before using each application because a user can potentially authenticate to as many as 10 different applications during a typical workday.  


Admins also have concerns with user credentials being submitted outside of the corporate network. This is due to the possibility of the user's traffic being intercepted or even key logging malware installed on remote machines. The concern is even greater with self-service registered device management features designed to allow users to do it anywhere and anytime.


To promote ease of use and increase security posture, customers can now use their own cloud identity provider as the primary authentication option for My Page. At the same time, admins can also be assured that all My Page user credentials are securely submitted for authentication. This is achieved by enabling the new SAML based IdP initiated option for My Page user authentication.


Now, users can easily authenticate to My Page with the same look and feel as other corporate apps they use daily. At the same time, credentials are securely submitted within a controlled trusted corporate network that is handled by a service external to RSA that  may very well be firewall-protected.


IT Help Desk Assisted Secure Device Registration


No matter how self-service a feature can be designed, some may still offer an admin assisted device registration option. Don't forget, registration issues may still happen and users still end up calling their IT Help Desk for further assistance. Since one of the goals of My Page is to help users register their own devices, only the user has access to information needed for device registration and not the admin. The user could screen-share their desktop with the admin during the help call; however, there should be an easier way to do this.



Admins can generate a code with a click of a button in the User Management section of the Cloud Administration Console. Admins can then provide this code to users over the phone. This can be used as part of an admin-assisted device registration process and even during registration troubleshooting because the generated one-time-use code is valid for a limited amount of time. 


Additional Deployment Option for RSA SecurID Authenticate for Windows


We are aware that some customers are restricting users from getting Windows Apps through the Microsoft Store. Instead, they prefer that these apps be distributed centrally similar to how it is traditionally done with other Windows apps in-use today. Admins can now use Deployment Image Servicing and Management (DISM) to deploy the app from a command-line tool. After the app is deployed, users can then complete RSA SecurID Authenticate device registration.  


For more information on these and other new features in the August 2019 RSA SecurID Access release, see the August 2019 Release Notes.

Insight into Identity Confidence

With this latest release of RSA SecurID Access, organizations will be able to view up-to-date identity confidence analytics information through the Cloud Administration Console. The analytics page will provide information on how many users were deemed risky based on the Identity Confidence policies set by the organization and what factors contributed to that risky behavior across their user population.  


Enable Auto-Push for RADIUS additional authentication Use Cases

When additional authentication is required for RADIUS clients, end-users can receive automatic push notifications (approve or biometrics) without any additional user interaction, providing a convenient end-user experience.   This capability can be configured under the RADIUS configuration page in the cloud authentication console. 


Enhanced security of FIDO token enrollment

Securely enroll FIDO based authenticators using the RSA SecurID Access My Page self-service portal. The My Page self-service enrollment portal allows organizations to protect FIDO registration with an access policy that is aligned with the organizations’ existing policies. Organizations will be able to optionally disable the FIDO token registration for their end-users which automatically occurs during user authentication and instead enable policy-protected enrollment through My Page.


Improved deployment options and supportability enhancements for the identity router

  • Flexible deployment options for identity routers. The identity router supports transparent, explicit, and man-in-the-middle proxy configurations. The identity router will inform if a non-RSA SSL proxy certificate is configured, and allow to temporarily accept the certificate and proceed while the administrator works with the network IT to whitelist the URL.
  • Identity router setup has been simplified. The proxy interface, which is not required for non-SSO deployments, is disabled by default in the Identity Router Setup Console. Enable as needed for SSO deployments.
  • Quickly identify potential problems that might occur while setting-up and monitoring identity routers using the improved status indicators in the Cloud Administration Console. The Platform > Identity Routers list page will provide more details on the status of each identity router and its dependent services, including the status of clusters, memory usage, CPU usage, and cloud connectivity

IP Address Changes - Please Plan in Advance!

To align with Microsoft Azure Resource Manager deployment model changes, the Cloud Authentication Service and Cloud Administration Console IP addresses will be changing in September 2019. Organization’s deployments must be able to connect to both new and old IP addresses in September 2019.


RSA recommends that you start planning with your organization now to make the necessary changes to connect to these new IP addresses. If the firewall rules are not updated with the new IP addresses, the identity routers will not be able to contact the Cloud Authentication Service.  This will cause disruption in the service. For details, see Notice of Upcoming Cloud Authentication Service IP Address Changes.

RSA continues to strengthen its RSA SecurID Access Cloud Authentication Service with the July product release.  For further details on all the new and updated capabilities of the July release, please refer to the Release Notes.

Calling all RSA Authentication Manager (AM) customers!  Interested in enabling your end users to have a more convenient and secure modern multi-factor authentication experience?   Now is the time to act. 


What is really exciting, is that you can enhance the end user experience without disrupting or changing your existing authentication agent infrastructure.  Users can authenticate using their SecurID pin + mobile "push-to-approve" to existing SecurID agents such as VPN, PAM and RADIUS clients without the need to disrupt existing user populations. 


RSA has just announced the release of RSA Authentication Manager 8.4 Patch 4 which has several new features that provides an easy and efficient approach to adopting multi-factor authentication.     

  • Accelerate the time value by simply clicking on new wizard button:  From the AM console, super administrators can easily connect RSA Authentication Manager to the cloud authentication service and perform a test authentication for validation.  This process will require you to copy a Registration Code and URL from the Cloud Authentication Service into the wizard to establish a one-way secure SSL channel between AM and the Cloud Authentication Service.  For additional security, add a proxy server.  
  • Invite users to register for modern mobile MFA directly from the Manage Users page in the RSA Authentication Manager console:  A default email template is provided which can be customized to meet your internal communication requirements.  Simply select the users and an email will be sent that includes the URL to My Page the new RSA SecurID Access Self Service Page.  Establish a policy that requires your selected users to login to My Page.  Several options are available including using their existing SecurID token for added security.  Once in My Page, users can register their mobile device and download the Authenticate App.
  • Unified Management Console: Help Desk administrators can manage mixed token / MFA deployments through the enhanced unified management capabilities of the AM User Dashboard to rapidly troubleshoot and resolve end user calls.   


Four Easy Steps to get started now

  1. Contact your RSA Sales Representative or you RSA Channel Partner to get your RSA Cloud Tenant provisioned.   Take advantage of the free MFA Promotion currently available.
  2. Deploy the Cloud Authentication Service (IDR and Cloud Tenant); Connect the Identity Router component to the same Identity Source that your RSA Authentication Manager is connected to. 
  3. Enable the new SecurID Access My Page self-service console; Select a policy to access My Page
  4. Download and install RSA Authentication Manager AM 8.4 Patch 4.  Click on the “Configure the Connection: Button from the AM Security Console to create the secure channel and invite users to register and enroll.


For more information, click here:  Modern-MFA

Seamless access to RSA My Page for self-service

To help make it easier for end users to enroll and manage their RSA Authenticate App we have enabled single-sign-on (SSO) support to RSA My Page from an external IDP.  In addition, you can also add your company logo for display during self-service.  These two features will allow seamless access for end users and provide a consistent user-branded experience.  



Important: Upcoming Cloud Authentication Service IP Address Changes

To align with Microsoft Azure Resource Manager deployment model changes, the Cloud Authentication Service and Cloud Administration Console IP addresses will be changing in September 2019. Your deployment must be able to connect to both new and old IP addresses in September 2019.


RSA recommends that you start planning with your organization now to make the necessary changes to connect to these new IP addresses. If you do not update your firewall rules with the new IP addresses, your identity routers will not be able to contact the Cloud Authentication Service and services will be disrupted. For details, see Notice of Upcoming Cloud Authentication Service IP Address Changes.


For further details on all the new and updated capabilities of the June release, please refer to the Release Notes here:  RSA SecurID® Access Release Notes: Cloud Authentication Service and RSA SecurID Authenticate App 


All these enhancements make RSA SecurID® Access and even more convenient, pervasive and intelligent solution for your authentication needs.

(Authored by Steve Schlarman, Portfolio Strategist, RSA)


It was Mark’s big shot.  He finally had a meeting with Sharon, the CIO.  Her schedule was so busy it was legendary and for her to spend time with a risk analyst was a clear indicator she recognized the new challenges facing their company.  Although he only had 15 minutes, Mark was prepared - notepad at the ready, brimming with nervous energy.   After some brief chit-chat he got down to business – ready to drill into a conversation about their company’s biggest obstacles; the most impactful concerns; the top of mind issues; the coup de grace that could spell disaster for the organization.  He took a deep breath and went to his big money question… ‘So, what keeps you up at night? What are you worried about?’ 


Sharon beamed.  She spun around to her white board and spewed a litany of projects fueling their company’s digital transformation – an IoT project, the implementation, a massive VMWare migration and their hybrid cloud, the new employee work-at-home program, the impending customer mobile portal…

While that question got Sharon started, let’s think about this a bit differently.


With all the benefits the new digital world offers, there are a host of risks that must be managed.   The major areas of risk remain the ‘usual suspects’ such as security, compliance, resiliency, inherited risks from third parties and operational risk. However, digital business amplifies uncertainty for organizations today.  For example:

  • Digital business, by its very nature, increases the threat of cyber incidents and risks around your intellectual property and customer data.
  • The expanded connectivity and expectations of the ‘always on’ business stresses the importance of resiliency.
  • Business has evolved into an ecosystem of internal and external services and processes leading to a complex web of ‘inherited’ risks.
  • The disappearing perimeter and digital workforce is challenging how organizations engage their customers and employees.


Factors such as these are why digital initiatives are forcing organizations to rethink and increasingly integrate their risk and security strategies. 


The objective for today’s risk professional is not just about defending against the bad.  Just like Mark discussing the parade of initiatives with Sharon that clearly impact their company’s future, you must be ready to help usher in a new age of digital operations.  Merely riding the buzzword wave - IoT, social media, big data analytics, augmented reality… - is not enough. 


You must look at opportunities to enable innovation in your business while building trust with your customers and throughout your enterprise.  Your business must be comfortable with embracing risk and aggressively pursuing market opportunities offered by new technology.  To do that, risk associated with the use of emerging or disruptive technology in transforming traditional business processes needs to be identified and assessed in the context of fueling innovation.   You also must keep focus on the negative side of risk.  Your business today demands an open, yet controlled, blend of traditional and emerging business tactics.  You must help manage the ongoing risk as these transformed business operations are absorbed into the organization fully, i.e. the new model becomes the normal model of doing business.


Risk is, by definition, uncertainty.  Everyone is concerned about uncertainty in today’s world.  However, if we go back to the simple equation (risk = likelihood * impact), risk should be something we can dissect, understand, and maybe even calculate.   While you are helping your organization embrace the advantages (positive risk) of technologies like IoT, data analytics, machine learning and other emerging digital enablers, the volatile, hyperconnected nature of digital business amplifies the negative side of risk.  It is anxiety about the unknown that leads us into that executive conversation, but it shouldn’t lead to worry.


Worry is about fear.  Your executives shouldn’t be afraid in today’s world.   They should have informed concerns.  And you – as the security or risk person in the room – should be feeding insights to raise their visibility of the likelihood of events and diminish their distress on the negative impacts.  Risk is part of riding the waves of business opportunities.

Risk is not something you should WORRY about…  it is something you should ACT on.


To learn more about digital risk management, click on our new Solutions Banners located in the right-hand column of each RSA product page: Third Party RiskCloud TransformationDynamic Workforce, and Cyber Attack Risk.

Don't miss our upcoming June product webinar tomorrow - June 12th at 11 am EST.    More details here on the webinar content and registration details - Don't Miss Our Upcoming June Product Webinar  


As always we will record this session and post the replay back to RSA SecurID Access:  All Access Granted 

In the past few months we have had conversations with many of you, our RSA SecurID® Access customers, who currently use RSA SecurID Hardware or Software tokens, about your journey to modernize authentication. We have heard you uncover three major themes:

  1. You need a simple, convenient way to extend multifactor authentication (MFA) to more types of users across the organization. Users who are on the go and need a simple and modern MFA experience.

  2. You need a faster, less obtrusive way to enable MFA for your existing users with tokens accessing existing resources protected by RSA SecurID today.

  3. You need to extend authentication to additional access uses cases such as SaaS applications and cloud infrastructure.


We love getting this kind of feedback for you because it helps us create solutions that can help you enable your business to grow securely.

In the upcoming June product release of RSA SecurID Access, an easy and efficient approach to adopting multi-factor authentication allows you to get faster time to value to achieve these goals, without needing to upgrade your existing authentication environment.


What's new?

Users can easily access existing resources protected by SecurID today including Virtual Private Network (VPN), Windows Desktop log-in, Linux/Unix based servers etc, with modern authentication methods including Push to Approve.


How is that done?

RSA SecurID authentication agents intercept access requests from users and direct these requests to the RSA Authentication Manager server for authentication. Once the system verifies users, they are granted access.


What does it mean for the end-users accessing resources?

Users can access RSA SecurID agent-protected resources with a secure and convenient authentication experience by simply entering their existing RSA SecurID PIN and tapping Approve on their registered devices. Or they can enter One-Time Password (OTP) tokencodes generated by the RSA SecurID Authenticate application. There is no need to replace or update your existing agents or RSA Ready products, and users do not need to memorize a new PIN.


What do you need to do to set this up?

Administrators can leverage a new wizard directly from the RSA Authentication Manager (AM) Security Console to set up and configure secure connections between AM and the Cloud Authentication Service. Invite users from the AM Manage Users page to enroll and register for MFA. This not only saves many configuration steps but minimizes training costs by using the AM console that is well known by your administrators and dramatically reduces the time to deploy.


Better Help Desk management?


Help Desk Administrators have a unified view from AM User Dashboard to manage a mixed deployment of tokens / MFA from a single console. This will result in much faster resolution of user help desk calls.


Achieve Faster Compliance at a Lower Cost


Immediately, expand MFA to new use cases and new users. Enable new users to create a PIN + Approve from their mobile device, eliminate passwords and achieve compliance. Lower cost by enabling MFA for third party contractors and suppliers. For token renewals, leverage MFA and lower token provisioning costs.

The Birth of Portable Computing

Computing in the modern world has changed drastically. Gone are the yesteryears when computers were big machines the size of your closet that is not very portable. Today, users demand portable computing whenever and wherever. In the Enterprise, efficiency is key. IT organizations are now open to provision more mobile devices such as smartphones, laptops and even tablets. This enables employees to be that much more productive on the go and ensures them reliable access to what they need; whenever, wherever.


Portable Computing Needs Untethered Security

IT organizations today recognize the need to secure these machines. However, what they fail to recognize is that these machines are often offline for many reasons. As an example, you need to login to your Windows laptop quickly because you are late for a very important customer call. However, your laptop is offline when you try to login; It is still trying to connect to the company network. Maybe, you are getting updated reports periodically about an urgent issue because you are mid-flight towards a remote data-center attempting to fix it. You want to be ready to go as soon as you land. However, your Windows tablet is offline because WiFi on-board is not freely available. Better yet, you need to login to your laptop quickly and email over a freshly signed Sales Order; all this to seal the deal before close of business. However, because you are onsite at that customer's office, your laptop is offline and has not connected to their Guest WiFi network at all.


These instances requires you to login first before establishing a network connection.You are effectively locked out of your machine if login while offline is not allowed. What then? Do we just create a backdoor Just-In-Case (a.k.a. Fail Open) login account? The answer cannot simply just be " No Network, No Secure Login Needed" for these whenever-wherever-machines.


Convenient & Seamless Windows Login Untethered, The RSA Way

Introducing, the All New RSA Multi-Factor Authentication (MFA) Agent for Microsoft Windows. This is our vision for users to securely and reliably login to Windows machines that is Convenient and Seamless whether Online or Offline. Anyone can claim that their product is reliable. This is because if something goes wrong, they can depend on users easily getting online and even stay online reliably while standing still.  These machines in the above examples are offline and  cannot connect to the authentication server to complete authentication. However, the user cannot get the machine back online unless they can login first. Good luck telling them to go to the nearest company office location just to login again.


This agent is designed from the ground up with the strength of the RSA Authentication Agent for Microsoft Windows (a.k.a Windows Agent); the convenience and secure modern authentication options of the RSA SecurID Access Cloud Authentication Service (CAS); all to secure Windows workstation and server logins.Not only is the ability for users to authenticate with different modern authentication methods that makes this agent unique; it is the ability for users to login Online or Offline, to their machines with the same authentication device and the same login experience. Imagine having to login multiple times a day and deciding which device to use for login all the time. You want convenient login and IT admins want secure login to your whenever-wherever-machines.


How RSA Does It... Better

The MFA Agent's Offline Authentication uses the Authenticate Tokencode; generated by the RSA SecurID Authenticate App. This is based on RSA's unique way of allowing tokencodes to be verified without network connectivity to the authentication server. What makes the MFA Agent's offline authentication even better than other solutions is the use of the same Authenticate Tokencode for both online or offline authentication. With our agent, an attacker cannot gain access to the machine console while malicious code cannot properly execute while the machine is offline. This is because most sensitive resources on an MFA Agent protected Windows machine requires a valid Authenticate Tokencode. To top it off, if users choose to login with an Authenticate Tokencode while online , they can also use the same device to generate an Authenticate Tokencode for login while offline.


This is what we do today with the classic Windows Agent using tokencodes generated by RSA's award-winning RSA SecurID tokens, deemed the Gold Standard for reliable and secure Offline Authentication. IT organizations cannot effectively secure and control a machine that is offline from an attacker that is either in front of the console, or already running as malicious code inside these machines. Large corporations and various governments globally have trusted it for many years to protect login to their most important Windows machines when offline; you can trust our MFA Agent to do the same for your whenever-wherever-machines.


Something Sweet For Servers Too

What about Windows Servers? Some equate non-portable Windows machines to never-offline-machines. What they learn is that servers can become offline due to a simple thing such as a patch applied gone wrong and simply un-assigns the server's IP address. Admins can only reconnect them to the network if they login to the server first. A lot of products out there will allow servers to "Fail Open" as a solution or even force admins to create a backdoor login account as  backup. Why find this acceptable? Use the all new MFA Agent to reliably secure server logins when offline, just like the rest of your whenever-wherever-machines.



As you go about evaluating a secure Windows Login solution, make sure you ask yourself "What happens to login when the machine is offline?" You will find that you either have to give up on security or convenience or both. Now, you don't have to anymore. With RSA, organizations can empower users with Convenient & Seamless Windows Secure Authentication - Untethered. For end users, this is like having your cake and eating it too - no strings attached.


Every customer who has adopted RSA SecurID Access’s risk engine capability to attain Identity Confidence, love and fully trust the capability.  Based on several discussions with you during the RSA conference and 1-1 sessions we realized that customers were looking for more visibility into the workings of risk engine to better understand how the risk engine can add value to your security policies. Specifically, you wanted to know why a user/group was challenged or what factors contributed to a user’s/group’s higher level of risk and hence lower identity confidence.


What did we do?

In May release, we have introduced a simple yet powerful capability through user event monitor to help solve visibility challenges. Below is a screenshot of the user event monitor for a user that sums up the entire feature. 

  • Confidence score  - Overall user identity confidence score. You can look at the aggregate confidence score across the entire user population (confidence Threshold) and benchmark a user’s confidence score against the aggregate score.
  • Category scores define what contributed to the overall confidence score. You can see if the low or high confidence score was driven more by the user’s device or by the location or by the user’s overall behavior or some combination thereof.  Category score consists of Device confidence, Behavior confidence, and Location confidence. 

The category scores (location, device & user behavior scores) are aggregated through a mathematical model to get the overall user level confidence score. 




For example, in the above screenshot user's confidence score is lesser than the aggregate score (confidence threshold) of the entire user population. In other words, the current user access request is riskier than the rest of the population and hence appropriate policy controls have to be in place to challenge the user with additional assurance. The reason for the user's lower confidence is more influenced by the lack of trust in the location from which the access request is coming from than the device from which the user request originates or the user's behavior. 


The lower the category (location, behavior or device) score is the lower the confidence is on that category. The system gains more trust by the continuous learning process on each of those categories over multiple access requests. This will eventually lead to higher confidence in each of those categories and hence the overall user confidence. 


How can these category scores add more value?

In addition to providing visibility into what contributed to the user's confidence level, these category scores can be used to determine the effectiveness of your security policies fully driven by identity context. For example, if admins see the device confidence is lower across a user set (ex: users within OU=Salesforce) leading to lower assurance across that user set (salesforce) the admin can try improving the device confidence and hence overall user confidence. One way to improve device confidence is to enable users with a managed device (through EMM/UEM).


Another great example could be how you can map your user or group level confidence (or risk) with better granularity to an IT application (as an RSA Archer IT asset) and make informed identity context driven risk management decisions. Possibilities are infinite with this enhanced visibility into RSA SID Access Risk Engine!


Hope the examples above help you in mapping some of the user level or group level identity risk factors to your organizational policies. As we learn more we plan to add more visibility and better way to control the risk engine so that you can take some meaningful actions impacting your identity risk posture.

Filter Blog

By date: By tag: