Activity Rule Professional
The activity rule monitors sign-in activity for enterprise applications and triggers non-compliance when applications haven't been used recently. This powerful rule helps identify unused integrations, optimize licenses, and reduce security risks.
Activity monitoring is available exclusively in the Professional plan. It applies only to Enterprise Application policies, not App Registration policies.
What the activity rule does
The activity rule checks when an enterprise application was last signed in to:
- Tracks sign-in activity: Monitors the last time users authenticated to the application
- Defines inactivity threshold: Triggers non-compliance after a configured number of days without sign-ins
- Supports automated cleanup: Enables workflows to identify and remove unused applications
Why use the activity rule
Identify unused integrations
Problem: SaaS applications, service principals, and third-party integrations may remain configured long after they're no longer used.
Solution: The activity rule automatically identifies applications that haven't been signed in to recently, flagging them for review.
Benefits:
- Reduce attack surface by removing unnecessary integrations
- Optimize license costs by identifying unused SaaS subscriptions
- Simplify your application portfolio
Support compliance and security
Problem: Compliance frameworks (SOC 2, ISO 27001, NIST) require periodic access reviews and removal of unused accounts and integrations.
Solution: The activity rule provides evidence that your organization monitors application usage and removes inactive integrations.
Benefits:
- Automated compliance reporting
- Demonstrates due diligence in access management
- Reduces risk of forgotten integrations being exploited
Enable data-driven governance
Problem: Without usage data, it's difficult to make informed decisions about which applications to keep, remove, or invest in.
Solution: The activity rule provides objective data about which applications are actively used.
Benefits:
- Support license optimization and cost allocation
- Inform strategic decisions about application portfolio
- Identify applications that may need training or promotion
How it works
Activity tracking
EasyLife 365 Identity retrieves sign-in activity data from Microsoft Entra ID:
- Daily sync: Activity data is updated daily for all enterprise applications
- Last sign-in date: Records the most recent successful user sign-in
- Inactivity calculation: Compares the last sign-in date to the configured threshold
Compliance evaluation
When a policy with an activity rule is applied:
- Check last sign-in: Compare the last sign-in date to the threshold
- Mark non-compliant: If no sign-in within the threshold, the app becomes non-compliant
- Send notifications: Notify application owners of non-compliance
- Re-evaluate daily: Check again each day (sign-in activity may resolve non-compliance automatically)
- Trigger escalation: If non-compliance persists, execute escalation actions
Automatic compliance restoration
Unlike ownership rules (which require manual action), the activity rule can self-resolve:
- User signs in: If someone signs in to the application, compliance is automatically restored
- No manual action needed: Owners don't need to click anything—usage resolves the issue
This makes the activity rule ideal for identifying truly unused applications while avoiding false positives for intermittently-used tools.
Configuration
Activity threshold
The number of days without sign-in activity before triggering non-compliance.
Common configurations:
| Threshold | Use Case |
|---|---|
| 30 days | Daily-use applications (email clients, productivity tools, dashboards) |
| 60 days | Weekly-use applications (reporting tools, internal portals) |
| 90 days | Monthly-use applications (batch jobs, scheduled tasks, periodic reports) |
| 120 days | Quarterly-use applications (compliance tools, seasonal applications) |
| 180 days | Annually-use applications (audit tools, emergency-only integrations) |
Example: If you set the threshold to 90 days, applications that haven't had a sign-in in the last 90 days will be marked non-compliant.
Notifications
Configure how owners are notified about inactive applications:
Notification count: Number of reminder emails sent before escalation Notification interval: Days between each notification
Example configuration:
- Threshold: 90 days
- Notifications: 3
- Interval: 7 days
Timeline:
- Day 90: Application becomes non-compliant, first notification sent
- Day 97: Second notification sent (if still non-compliant)
- Day 104: Third notification sent (if still non-compliant)
- Day 111: Escalation triggered (if still non-compliant)
Escalation
Define what happens if the application remains inactive after all notifications:
Email escalation: Send email to governance team, IT leadership, or compliance team
Webhook escalation: Trigger automated actions in external systems
Common escalation actions:
- Create a ticket in ITSM system (ServiceNow, Jira)
- Trigger a Logic App to disable the application
- Send data to a compliance dashboard
- Archive the application to a "quarantine" state
Use cases
Quarterly application review
Goal: Identify applications that should be reviewed for removal every quarter.
Configuration:
- Activity threshold: 90 days
- Notifications: 2 (14 days apart)
- Escalation: Email to IT governance team
Workflow:
- Applications with no activity in 90 days are flagged
- Owners receive 2 notifications over 28 days
- If still inactive, escalation email sent to governance team
- Governance team reviews and decides to keep, archive, or remove
License optimization
Goal: Identify SaaS applications with low usage to reclaim licenses.
Configuration:
- Activity threshold: 30 days
- Notifications: 1 (immediate)
- Escalation: Webhook to create ServiceNow ticket
Workflow:
- SaaS applications with no sign-ins in 30 days are flagged
- Owners are notified immediately
- If no sign-in within 7 days, ticket created in ServiceNow
- License manager reviews usage and reclaims unused licenses
Security hardening
Goal: Remove dormant service principals that could be security risks.
Configuration:
- Activity threshold: 60 days
- Notifications: 3 (7 days apart)
- Escalation: Webhook to Logic App that disables the app
Workflow:
- Service principals with no activity in 60 days are flagged
- Technical owners receive 3 notifications over 21 days
- If still inactive, Logic App automatically disables the service principal
- Security team is notified of the automated action
Compliance reporting
Goal: Generate reports showing that only necessary integrations are maintained.
Configuration:
- Activity threshold: 90 days
- Notifications: 1 (immediate)
- Escalation: Webhook to Power BI for compliance dashboard
Workflow:
- Applications with no activity in 90 days are flagged
- Owners are notified
- Data is sent to Power BI for compliance reporting
- Compliance team exports reports for SOC 2 audits
M&A integration cleanup
Goal: Clean up inherited applications after a merger or acquisition.
Configuration:
- Activity threshold: 60 days (shorter for aggressive cleanup)
- Notifications: 3 (14 days apart)
- Escalation: Email to integration architecture team
Workflow:
- Inherited applications with no activity in 60 days are flagged
- Assigned owners (from the acquired company) are notified
- Over 42 days, owners confirm whether apps are still needed
- Escalation to architecture team for final review and removal
Best practices
Set realistic thresholds
Consider the application's actual usage pattern:
Too aggressive: 30-day threshold for monthly batch jobs will create false positives
Too lenient: 365-day threshold may not identify truly unused applications
Recommendation: Start with 90 days for most applications, then adjust based on your organization's usage patterns.
Combine with ownership rules
Use activity and ownership rules together:
Activity rule: Identifies unused applications
Ownership rules: Ensure someone is responsible for responding
Example policy:
- Minimum application owner: 1
- Minimum technical owner: 1
- Activity threshold: 90 days
Result: Every app has a designated owner who will receive notifications if the app becomes inactive.
Handle false positives
Some applications may appear inactive but are still needed:
Background services
Problem: Service principals for batch jobs, scheduled tasks, or background processing may not generate sign-in events detected by Entra ID.
Solution: Create a separate policy with a longer activity threshold (180-365 days) or no activity rule.
Emergency-only tools
Problem: Disaster recovery applications, emergency access accounts, or break-glass procedures are used rarely but must remain available.
Solution: Exclude these applications from activity policies or use exemption policies with no activity rule.
Seasonal applications
Problem: Applications used only during specific periods (annual reviews, tax season, enrollment periods) may be inactive for months.
Solution: Use longer activity thresholds (180-270 days) or manual confirmation workflows.
Use graduated enforcement
Start lenient and tighten over time:
Phase 1 (Months 1-3):
- Threshold: 180 days
- Notifications: 1
- Escalation: Email only
- Goal: Identify obvious candidates for removal
Phase 2 (Months 4-6):
- Threshold: 120 days
- Notifications: 2
- Escalation: Create tickets
- Goal: Build confidence in the process
Phase 3 (Months 7+):
- Threshold: 90 days
- Notifications: 3
- Escalation: Automated remediation
- Goal: Continuous, automated governance
Monitor and adjust
Regularly review the effectiveness of your activity policies:
Weekly: Check applications approaching escalation
Monthly: Review escalation outcomes (how many apps were removed vs. kept)
Quarterly: Adjust thresholds based on false positive rates
Metrics to track:
- Number of applications flagged
- Percentage resolved by renewed usage
- Percentage resolved by manual confirmation
- Percentage escalated
- Percentage actually removed
Limitations and considerations
Sign-in data availability
The activity rule depends on sign-in data from Microsoft Entra ID:
- Not all activity generates sign-ins: Backend services, service-to-service authentication, and certificate-based auth may not create detectable sign-in events
- Data retention: Historical sign-in data may be limited in Microsoft Entra ID
- Sync frequency: Activity data is updated daily, not real-time
Activity vs. usage
Sign-in activity indicates authentication but not actual usage:
- An application may be signed in to but not actively used
- An application may be used without generating sign-in events
For true usage monitoring, combine the activity rule with application-specific usage data from the SaaS provider.
Professional plan requirement
The activity rule is only available in the Professional plan:
- Organizations on the Basic plan can still use ownership rules for governance
- Consider upgrading to Professional if activity monitoring is important for your use case
Enterprise Applications only
The activity rule applies only to Enterprise Application policies:
- App Registrations do not support activity monitoring
- Focus activity governance on enterprise applications and service principals
Related concepts
- Activity Monitoring - Understand how activity tracking works across EasyLife 365 Identity
- Policies - Learn about policy evaluation and escalation
- Enterprise Application Policies - See the activity rule in action
- Ownership Rules - Combine activity and ownership for comprehensive governance