Multifactor policy configuration
Overview
This article shows how administrators can require extra verification of users by configuring a multifactor policy. Extra verification improves account security, because attackers cannot log in even if they gain access to the user's password.
Examples here assume users are logging in to Jira using password as their primary authentication factor. When using other Atlassian applications or primary factors (SAML, Kerberos), the experience is very similar.
Before an admin is allowed to configure multifactor policies, at least one extra verification factor must be registered on their account. This restriction exists to make sure admins can themselves register successfully before making it a requirement for other users.
Adding a policy
Start by visiting the Policies page and clicking the Add policy button:
Select the Multifactor policy type, then click Add
Give the policy a name which in a few words describes the purpose of the policy:
Enrolled users
The Enrolled users section determines what type of action is enforced for users who have already enrolled at least one extra verification factor:
Users may either be required to verify every time they log in, or they can be allowed to 'remember' verification on devices they trust, thus allowing them to verify only once per device. If you only want this policy to enforce enrolment in extra verification (and not actually require verification), then select 'Log in as usual').
Unenrolled users
This section determines what should happen when users log in and the user has not yet enrolled in extra verification:
Users may either be forced to enrol a verification factor, or they may be encouraged to do so, meaning they are allowed to skip enrolment and do it at a later time. The Cannot log in is useful in cases where users are assumed to be enrolled up front, or when you have another policy which allow users to enrol only from the internal network. Select Log in as usual if you don't want this policy to enforce enrolment of verification factors.
Conditions
Use the conditions section if you want the policy to only match a certain subset of users, users logging in from certain network locations or using certain primary login methods.
When a user logs in, only policies which match all conditions will have effect for the user. If multiple policies match, then the policy with the most strict security wins. For example: A policy which requires verification on every login will always 'win', even when a policy which allows verification once-per-device also matched.
Running a test evaluation
Once you policy has been added, you might want to perform a simulated login to verify that the policy matches the login conditions you expect. Click the Simulate policy evaluation link on the Policies page:
The result shows which policies match and which effective actions would be taken:
See it in action
See how to add a multifactor policy, and the end user experience when registering and logging in using a USB security key without user verification such as PIN or fingerprint support.