Policies control various aspects of your deployment:
Token policies. A token policy defines users’ RSA SecurID PIN lifetime and format, and fixed passcode lifetime and format, as well as how a deployment handles users or unauthorized people who enter a series of incorrect passcodes.
Lockout policies. A lockout policy defines how many failed logon attempts users can make before Authentication Manager locks their account, and how the account can be unlocked: either automatically or by administrator intervention.
Offline authentication policies. An offline authentication policy defines the way users authenticate when they are not connected to the network (for example, when users work away from the office or when network conditions make the connection temporarily unavailable).
Password policies. A password policy defines users’ password length, format, and frequency of change.
Self-service troubleshooting policies. The self-service troubleshooting feature allows Self-Service Console users to troubleshoot routine authentication problems when they cannot access protected resources using primary methods, such as passwords or passcodes.The self-service troubleshooting policy defines an alternative form of authentication, such as security questions, used to access the Troubleshooting feature. The policy also specifies the circumstances that lock a user out of the Troubleshooting feature.
Workflow policies. Self-Service uses workflow policies to automate deployment of authenticators and to fulfill other requests from users, for example, on-demand authentication (ODA).
Risk-based authenticaton policies. Risk-based authentication (RBA) strengthens RSA SecurID and password-based systems by applying knowledge of the client device and user behavior to assess the potential risk of an authentication request. RBA policies determine how this feature works in each domain.
Authentication Manager provides a default of each policy type and assigns them to each new security domain. You can also assign a custom policy. If you designate a new default policy, the new default policy is automatically assigned to existing security domains that use the default policy and to new security domains.
The policy assigned to a lower-level security domain is not inherited from upper-level security domains. New security domains are assigned the default policy that is in place at the time they are created, regardless of which policy is assigned to security domains above them in the hierarchy. For example, if the top-level security domain is assigned a custom policy, lower-level security domains are still assigned the default policy.