Action & Rules: Mastering Authsignal's Rules Engine

In our previous article, we learned how Authsignal actions serve as the foundation for contextual, risk-based authentication. Now, let’s dive deeper into the second critical component: Authsignal's rules engine, the intelligent decision-making system that determines when and how to challenge users.

‍

What are rules in Authsignal?

Rules are conditional statements that evaluate the context of each action to make intelligent security decisions. While actions define what users are doing, rules determine when and how to challenge them based on risk factors.

Authsignal's rules engine analyzes various data points collected during an action from device characteristics and IP information to user behavior patterns and transaction details to decide whether to allow the action, challenge the user with authentication, send it for manual review, or block it entirely.

‍

The power of no-code rules

What makes Authsignal's rules engine even more powerful is its no-code interface. This means:

• Rules can be updated in real-time without code deployments
• Business users can respond quickly to emerging threats
• Testing and iterating on security policies becomes much faster

Let's explore how to create and manage rules for smarter authentication flows.

‍

Creating your first rule

To create a rule in Authsignal, navigate to the specific action you want to secure (like "withdraw-funds") and get to rules tab.

The rule creation process consists of three key components:

1. Rule identification - Give your rule a clear, descriptive name and description
2. Conditions - Define the criteria that will trigger the rule
3. Outcome - Specify what happens when the conditions are met

‍

Rule identification

Start by providing a meaningful name that helps your team understand the rule's purpose at a glance. For example:

• "High-value transfer review"
• "New device challenge"
• "Block suspicious logins"

Including a detailed description makes it easier for team members to understand its purpose.

‍

Setting up conditions

Conditions are the core of your rule. This is where you define exactly what circumstances should trigger the rule's outcome.

‍

Authsignal provides a rich set of data points to build conditions, for example:

Device and network data

• Device characteristics: Is this a new device? Is it using an emulator or jailbroken OS?
• IP information: Is the user connecting from an anonymous IP, VPN, or Tor exit node?
• User agent details: Browser type, operating system, and more

User context

• Enrollment status: Which authenticators has the user set up?
• Account information: Email address, phone number, etc.

Custom data points

• Your business-specific data: Any additional context provided in the custom attributes when tracking an action

When building conditions, you can combine multiple criteria using logical operators (AND/OR) to create precisely targeted rules.

‍

Example condition: New device detection

A common rule is to challenge users who are accessing from a new device. Here's how to set it up:

1. Create a new rule named "Challenge new devices"
2. Add a feature from the Device category
3. Select "Device is new"
4. Set the rule's outcome to "CHALLENGE"

This simple rule dramatically improves security by requiring additional verification whenever a user accesses from an unfamiliar device.

‍

Specifying outcomes

When a rule's conditions are met, Authsignal offers four possible outcomes:

• ALLOW: Let the action proceed without additional authentication
• CHALLENGE: Require the user to complete an authentication challenge
• REVIEW: Place the action in a queue for manual review
• BLOCK: Prevent the action from proceeding entirely

Each outcome has its own use cases:

• Use ALLOW for low-risk scenarios or trusted contexts
• Use CHALLENGE for medium-risk scenarios where verification is prudent
• Use REVIEW for high-risk scenarios requiring human judgment
• Use BLOCK for clear fraud or policy violations

‍

Advanced rule settings

Beyond the basic conditions and outcomes, there are several advanced settings that give you even more control over your security policies:

1. Authenticator override settings

When a rule triggers a CHALLENGE outcome, you can override the default authenticator settings for that specific action:

‍

‍

This allows you to require stronger authentication methods in higher-risk scenarios:

• Override permitted authenticators: Force the use of specific authentication methods, such as requiring passkeys or TOTP for high-value transfers, even if other methods are normally allowed
• Override user's default authenticator: Change which authenticator is presented first, regardless of the user's usual preference

2. Passkey promotion

When configured, Authsignal can prompt users to create a passkey after completing a challenge:

‍

This is a great way to gradually transition your user base to more secure authentication methods without disrupting their experience.

3. Metadata

Rules can also store additional metadata for analytics and reporting purposes:

This custom information can help you track the effectiveness of different security policies and make data-driven decisions about your authentication strategy.

‍

Rule priority and evaluation

When multiple rules could apply to a single action, Authsignal evaluates them in priority order:

Rules higher in the list are evaluated first, and the first matching rule determines the outcome. This allows you to create a cascade of security policies, from specific high-priority rules to more general fallback rules.

You can easily reorder rules by dragging them up or down in the list, ensuring that your most critical security policies take precedence.

‍

Real-world rule examples

Let's look at some practical examples of rules you might implement in different scenarios:

‍

Financial services

For a payment app, you might create rules like:

1. High-value transaction challenge
   • Condition: Transaction amount > $10,000
   • Outcome: CHALLENGE with passkey only
2. Unusual destination review
   • Condition: Transfer to a recipient added in the last 24 hours AND amount > $5,000
   • Outcome: REVIEW
3. Suspicious Location block
   • Condition: IP address is anonymous OR user is in sanctions list
   • Outcome: BLOCK

‍

E-commerce

For an online store, you can consider rules like:

1. New account verification
   • Condition: User account created < 7 days ago AND order value > $1,000
   • Outcome: CHALLENGE
2. Unusual shopping pattern
   • Condition: Order count in last hour > 5
   • Outcome: CHALLENGE
3. Address Mismatch Review
   • Condition: Shipping address country ≠ billing address country
   • Outcome: REVIEW

‍

SaaS applications

For a business application, you might implement:

1. Admin action verification
   • Condition: Action = "change-permissions" OR action = "bulk-delete"
   • Outcome: CHALLENGE with TOTP only
2. Off-hours access
   • Condition: Time is outside business hours AND action = "access-sensitive-data"
   • Outcome: CHALLENGE and notify admins
3. API key rotation enforcement
   • Condition: API key age > 90 days
   • Outcome: CHALLENGE

‍

Monitoring rule effectiveness

Once you've created rules, it's important to understand their impact on your users' authentication experience. Authsignal provides powerful analytics tools to help you measure and optimize your rules. These are:

‍

Rule impact analysis

When editing or creating rules, Authsignal offers a rule impact analysis feature that helps you understand how your rule changes will affect user outcomes:

‍

This analysis uses activity data from the past 7 days to estimate how your rule will impact users going forward. Key metrics include:

Rule trigger frequency

The impact analysis shows:

• Actual triggers: How many times the rule would have triggered with its current conditions
• Estimated triggers: How many times it would trigger with your proposed changes

This helps you understand if your rule changes would make the rule more or less selective. In the example above, the rule changes would reduce triggers by 37%, indicating a more targeted approach.

User action outcomes

The most valuable aspect of impact analysis is seeing how your rule changes would affect the outcomes users experience:

• Allow impact: How many more (or fewer) users would be allowed to proceed without challenges
• Challenge impact: How many more (or fewer) users would face authentication challenges

In the example shown, the rule changes would result in 34% more allows and 37% fewer challenges. This is valuable for finding the right balance between security and user experience.

‍

Real-time rule analytics

Beyond the impact analysis for planning changes, Authsignal also provides ongoing analytics for your active rules:

• Rule effectiveness: Which rules are triggering most frequently
• Outcome distribution: The breakdown of ALLOW, CHALLENGE, REVIEW, and BLOCK outcomes
• User impact: How rules are affecting different user segments

These metrics help you continuously refine your security posture, identifying rules that may be too strict (causing unnecessary friction) or too lenient (creating security gaps).

‍

Custom data points and user persistence

One of the powerful features of Authsignal's Rules Engine is its flexibility in working with custom data. There are two primary ways to leverage custom data in your rules:

1. Run-time custom data points

Run-time custom data points are values that are available at the moment an action occurs. These are dynamic, contextual pieces of information that you include in the attributes object when tracking an action. Examples include:

• Transaction amounts for financial applications
• Destination accounts or wallet addresses
• Order values for e-commerce platforms
• Business logic flags like "isFirstWithdrawal"
• Time-based information like account age or recent activity counts

These run-time values can be used in rules to make decisions about the current action, allowing for precise, contextual security decisions based on what the user is doing right now.

2. Persisted user custom data

While run-time data provides context for the current action, sometimes you need to persist data at the user level to track patterns or maintain state across multiple actions. Authsignal allows you to synchronize custom data to a user's profile, including:

• Internal risk scores
• Verification status (like KYC completion)
• Historical transaction volumes
• Known login locations or devices
• Authentication history and patterns
• Business-specific user attributes

Once stored, these custom user attributes persist across sessions and can be used in rules to make decisions based on user history and profile, not just the current action.

‍

Creating sophisticated rules

The real power comes from combining these approaches. For example, you might create a rule that challenges a user when:

"The current transaction amount is greater than 20% of their total transaction volume AND their risk score is above 50"

This rule references both run-time data (current transaction amount) and persisted data (total transaction volume and risk score), creating a highly contextual security policy.

We'll dive deeper into implementing custom data points with code examples in part three of our series.

‍

Best practices for rules

Based on our experience working with customers across various industries, here are some best practices for implementing effective rules:

1. Start simple and iterate

Begin with a few basic rules targeting your highest-risk scenarios, then gradually expand your ruleset as you learn what works for your specific use case. Monitor the impact of each new rule and be prepared to adjust as needed.

2. Use a layered approach

Create multiple levels of security by combining different types of rules:

• Baseline rules that apply to all users
• Contextual rules that consider user behavior patterns
• Specific rules for high-risk actions or user segments

3. Balance security and user experience

While it's tempting to challenge users frequently, excessive friction can lead to frustration. Use rules to apply security proportionally to risk, challenging users only when necessary.

4. Regularly review and update rules

Security is not a set-it-and-forget-it task. Schedule regular reviews of your rules to ensure they're still aligned with your security needs and user expectations.

5. Document rule logic

Maintain clear documentation of what each rule does and why it exists. This helps maintain continuity when team members change and makes troubleshooting easier.

‍

Conclusion

Authsignal's rules engine transforms basic authentication flows into intelligent, risk-based security systems. By evaluating the context of each action and applying appropriate security measures, you can significantly improve both security and user experience.

The no-code interface makes it accessible to security teams and business users, allowing for rapid response to emerging threats without much developer resources. The rich set of data points and conditions enables highly targeted rules that apply security precisely where it's needed.