Enterprise mobility has evolved far beyond simply delivering a mobile application to users. Today, organizations expect apps to align with enterprise security standards, support flexible deployment models, and operate seamlessly across managed and unmanaged environments.

One of the most significant challenges is supporting Microsoft Intune Mobile Application Management (MAM) without fragmenting the product into separate builds, client-specific forks, or independent distribution pipelines.

Over the past few months, we worked on solving exactly this challenge for AI CardVault.

• Microsoft Intune MAM integration
• Multi-client and multi-tenant architecture
• Managed enterprise environments
• Non-MAM users and standard application flows
• Conditional Access–driven authentication behavior

All of this now operates within a single, unified application.

This was not simply an SDK integration exercise. It required us to rethink how the application handles enterprise policies, client-specific configuration, authentication, user context, and deployment flexibility at scale.

About AI CardVault

AI CardVault simplifies professional networking and enterprise contact management through secure, scalable, and intelligent digital business card solutions.

As enterprise adoption increased, organizations began requiring compatibility with Microsoft Intune App Protection Policies to meet their security and compliance standards. We therefore enhanced AI CardVault with Intune MAM support while preserving multi-client architecture and support for users outside MAM-managed environments.

The result is a unified application that enterprises can deploy across different security models without maintaining separate app versions or disrupting existing user workflows.

Why Intune MAM Matters

Modern organizations operate in increasingly hybrid environments. Employees may use both company-managed and personal devices to access corporate applications and data.

In many of these scenarios, enterprises need to protect corporate information without taking full administrative control of a user’s device. This is where Microsoft Intune Mobile Application Management becomes important.

Unlike Mobile Device Management (MDM), which manages the device and its compliance posture, MAM focuses on protecting organizational data at the application level. Depending on configured policies, enterprises can control how corporate data is accessed, transferred, and removed from managed apps.

• Protect corporate application data
• Enforce app-level security policies
• Restrict copy, paste, and data sharing
• Support selective removal of organizational data
• Enable BYOD (Bring Your Own Device) scenarios
• Maintain separation between personal and corporate data

For enterprises, this flexibility is extremely valuable. For application teams, however, it introduces meaningful architectural complexity.

The Challenge We Faced

AI CardVault was originally designed for standard application environments. As enterprise requirements expanded, we needed to support organizations using Intune App Protection Policies and Microsoft Conditional Access.

The challenge was not simply enabling MAM. We needed one product architecture capable of supporting MAM-enabled clients, non-MAM clients, multiple enterprise tenants, different policy requirements, and different deployment expectations.

A common response to these requirements is to create separate enterprise builds, configuration layers, deployment pipelines, or client-specific forks. While this can work initially, it quickly increases maintenance cost and release complexity.

We wanted a more scalable approach.

Implementation Challenges We Faced — and How We Solved Them

1. Conditional Access Behaved Differently on iOS and Android

Challenge: During testing, Conditional Access behavior was not identical across Android and iOS. Android unmanaged-device scenarios were blocked as expected under our enterprise configuration, while some iOS authentication scenarios still completed Microsoft sign-in when stronger device enforcement was expected.

Why it happened: The authentication and broker ecosystems differ between platforms. Android commonly works closely with Company Portal in enterprise flows, while iOS authentication typically involves Microsoft Authenticator as the broker. Device compliance, app protection, and access evaluation can also surface at different points in the authentication and policy flow.

Solution: We redesigned the authentication architecture around broker-aware MSAL sign-in, Intune App Protection readiness, Conditional Access–aware token handling, and native compliance remediation where required.

Most importantly, Microsoft Entra ID and Intune remain the source of truth for access decisions. The application does not rely on hardcoded assumptions about whether a platform or device should be allowed.

2. Integrating Microsoft SSO and Intune MAM into a Flutter App

Challenge: Flutter provides a shared cross-platform application layer, but Microsoft authentication and Intune policy integration still require platform-specific native behavior. We needed to preserve a unified Flutter experience while supporting native enterprise capabilities on iOS and Android.

What we needed to solve: The solution had to support secure Microsoft sign-in, Intune enrollment for applicable clients, backend login only after successful authentication, multi-tenant client configuration, and clear handling of unmet enrollment or policy requirements.

Solution: We built a unified Flutter authentication flow with native method-channel bridges for iOS and Android.

1. Client and SSO discovery
2. Microsoft MSAL authentication
3. Intune MAM enrollment or policy handling where required
4. Backend session creation

This sequence preserves one product experience while allowing each platform to perform the native work required for enterprise authentication and protection.

3. App-Side Device Checks vs. Microsoft Conditional Access

Challenge: To address early iOS enforcement gaps, we introduced an application-level managed-device check. This created an unintended problem: login could still fail when Conditional Access restrictions were disabled because the app itself continued enforcing device restrictions.

Key learning: Enterprise access decisions should be driven by the organization’s Microsoft Conditional Access and Intune configuration rather than duplicated through hardcoded application rules.

Solution: We removed the hardcoded MDM gate and aligned the application with Microsoft-driven policy control. This made behavior easier to test and ensured that personal-device and company-device access followed each client’s actual Entra ID and Intune configuration.

4. MAM Success Does Not Always Mean MDM Compliance

Challenge: During testing, MAM enrollment could succeed on personal devices. Initially, this created confusion about whether successful enrollment meant the device itself was organization-managed.

Clarification: MAM protects application data and the managed application context. MDM manages the device and contributes to device compliance state. A personal device can participate in an app protection flow without becoming a fully organization-managed device.

Solution: We aligned product behavior and client guidance with the intended Microsoft policy model.

This distinction is critical when enterprises define their security posture.

5. Enterprise Environment Setup and End-to-End Testing

Challenge

One of the most time-consuming parts of the Intune MAM implementation was not application development itself — it was preparing a complete Microsoft enterprise environment and validating the end-to-end authentication and policy flow.

Testing Microsoft Intune MAM and Conditional Access requires multiple Microsoft services and configurations to work together correctly. A small configuration mismatch can result in behavior that initially appears to be an application issue.

Before meaningful end-to-end testing could begin, we needed to configure and validate the Microsoft Entra ID tenant and complete the Microsoft application registration process.

Microsoft provides detailed guidance for registering applications with the Microsoft identity platform in its official documentation:

Microsoft identity platform — Register an application

The application registration required platform-specific configuration for iOS and Android, including redirect URIs, authentication settings, and Microsoft Authentication Library (MSAL) integration.

Microsoft’s mobile application authentication configuration is documented here:

Microsoft identity platform — Mobile application configuration

We also needed to configure the required API permissions and consent model correctly. Missing permissions or incomplete administrator consent can directly affect authentication and access to protected resources.

Microsoft documents API permission configuration here:

Microsoft identity platform — Configure API permissions

After completing the authentication setup, the next major step was configuring Microsoft Intune App Protection Policies.

These policies define how corporate data is protected inside the application and can control data transfer, copy and paste behavior, application access requirements, and selective removal of organizational data.

Microsoft’s official Intune App Protection documentation is available here:

Microsoft Intune — App Protection Policies

Conditional Access was another critical part of the testing environment.

We needed to configure policy assignments, target users and groups, exclusions, grant controls, and the relationship between Conditional Access and Intune App Protection Policies.

Microsoft explains app-based Conditional Access and its integration with Intune here:

Microsoft Intune — App-based Conditional Access

The broker authentication environment also required platform-specific validation.

On supported iOS app-based Conditional Access flows, Microsoft Authenticator acts as the broker application. On Android, Microsoft Company Portal is used for supported broker and app protection scenarios.

This meant our test environment needed to validate authentication and policy behavior separately across iOS and Android.

Why Testing Became Complex

Enterprise policy testing is significantly different from standard application testing.

The final authentication and access result depends on multiple layers working together:

AI CardVault → MSAL → Microsoft Broker → Microsoft Entra ID → Conditional Access → Microsoft Intune App Protection Policy → Device or Application State

Because of this architecture, a failed login or unexpected access result does not automatically indicate an application defect.

The issue may originate from:

• Incorrect Microsoft Entra application registration
• Missing or invalid redirect URIs
• Incorrect Android package or signature configuration
• Missing API permissions or administrator consent
• Missing Microsoft Intune or Entra licensing
• Incorrect user or security group assignments
• App Protection Policies targeting the wrong application or users
• Conditional Access policy assignments or exclusions
• Broker configuration differences between iOS and Android
• Device enrollment or compliance state
• Policy propagation and evaluation timing

Solution

We created a structured enterprise testing process instead of validating only the Flutter application code.

For every enterprise authentication scenario, we verified:

1. Microsoft Entra application registration and platform configuration
2. MSAL authentication configuration
3. Required API permissions and administrator consent
4. User licensing and security group assignments
5. Microsoft Intune App Protection Policy assignment
6. Conditional Access policy targeting and grant controls
7. Broker application availability and platform requirements
8. Device enrollment or compliance state
9. Microsoft sign-in and Conditional Access results
10. Final AI CardVault backend authentication behavior

For the iOS Intune integration, we also followed Microsoft’s Intune App SDK and MSAL integration requirements:

Microsoft Intune App SDK for iOS — MSAL prerequisite and integration

We tested multiple enterprise access scenarios, including:

• MAM-enabled users on personal devices
• MAM-enabled users on managed devices
• Device-compliance-required environments
• Non-MAM clients
• Conditional Access enabled and disabled scenarios
• iOS Microsoft Authenticator broker flows
• Android Company Portal broker flows

Key Learning

Enterprise integration testing requires almost as much attention as the implementation itself.

A successful Intune MAM integration cannot be validated only from the application layer. Microsoft Entra ID, Intune, Conditional Access, application registration, API permissions, policy assignments, licensing, broker applications, and device state must all be configured and tested as one complete enterprise system.

For us, building a repeatable Microsoft test environment and a structured validation process was a critical part of delivering reliable enterprise support.

Our Approach: One Unified Application

Instead of creating multiple versions of AI CardVault, we redesigned the architecture to support dynamic enterprise behavior within a single codebase.

The goal was straightforward: one application capable of adapting to managed and unmanaged environments based on client configuration and Microsoft policy decisions.

The application needed to detect and handle MAM-enabled scenarios, support multiple client configurations, preserve standard flows for non-MAM users, and maintain a consistent experience across platforms.

• Authentication and broker flows
• Policy initialization and protected application states
• Runtime client configuration
• Tenant-level separation
• Conditional enterprise behavior
• Enterprise security controls

The result is a single application architecture capable of operating across diverse enterprise environments without sacrificing maintainability.

What Makes This Implementation Different

Many discussions about Intune integration focus primarily on adding SDK support. In a production enterprise application, SDK integration is only one part of the solution.

Our implementation is built around three principles.

1. Multi-Client Flexibility

Different clients operate under different security policies and enterprise expectations. Some require Intune App Protection Policies and Conditional Access controls; others operate outside MAM environments.

AI CardVault supports these models within the same application architecture without requiring a separate deployment for each client.

2. Seamless Managed and Non-Managed Support

A major priority was ensuring that enterprise integration did not negatively affect standard users. Applications can become overly dependent on enterprise frameworks after MAM integration, creating unnecessary friction for users outside managed environments.

In AI CardVault, managed users receive policy-aware protection while non-MAM users continue through their standard flows. Both experiences coexist within the same product.

3. A Scalable Enterprise Architecture

Enterprise requirements rarely remain static. Security policies evolve, new clients introduce different requirements, and compliance expectations continue to grow.

Rather than building a fixed, client-specific integration, we focused on an extensible enterprise foundation that can support future policy and authentication enhancements.

Technical Considerations Behind the Implementation

Policy-Aware Application Behavior

The application must respond correctly when enterprise policies are applicable. This includes protected data flows, managed application states, conditional restrictions, and policy-driven enforcement.

Runtime Configuration Management

Supporting multiple clients in one application requires dynamic configuration. Different organizations may use different authentication models, policy sets, and enterprise controls.

Our architecture separates client configuration from the core product flow so enterprise behavior can vary without creating separate applications.

Cross-Platform Conditional Access Support

Because iOS and Android use different native broker and policy integration paths, the authentication architecture must provide a consistent product flow while respecting platform-specific Microsoft behavior.

Backward Compatibility

Preserving existing user behavior was one of our highest priorities. The implementation was designed to remain compatible with existing deployments, non-managed environments, and established user flows.

This allowed us to improve enterprise readiness without fragmenting the product.

Why This Matters for Enterprises

Faster Enterprise Onboarding

Organizations with Intune security requirements can adopt AI CardVault without waiting for a separate enterprise build.

Reduced Maintenance Complexity

Maintaining one application architecture reduces development overhead, release-management complexity, duplicated testing, and deployment risk.

Better Scalability

As new enterprise clients onboard, varying policy and authentication requirements can be supported more efficiently through configuration and policy-aware behavior.

A Consistent User Experience

Users receive a consistent product experience while the application adapts to the enterprise controls applicable to their context.

Clearer Policy Alignment

The architecture follows Microsoft Conditional Access and Intune policy models rather than duplicating enterprise access decisions inside the application. Enterprises can therefore choose controls that match their goals: MAM for protected BYOD scenarios or device compliance requirements for stricter managed-device access.

Key Learnings from This Journey

One of our most important realizations was that enterprise readiness is not only about security compliance. It is also about adaptability.

Modern enterprise applications must account for hybrid work, mixed device ownership, platform-specific authentication behavior, diverse security requirements, and client-specific operating models.

Building for these realities requires an architecture that can adapt to policy and client context rather than adding enterprise support as an isolated layer.

Enterprise readiness is not only about integrating SDKs. It is about handling policy differences, platform behavior, and client-specific security models correctly within one unified application.

Looking Ahead

Enterprise mobility continues to evolve rapidly. Organizations are increasingly prioritizing zero-trust security models, application-level data protection, flexible BYOD strategies, and unified enterprise experiences.

Our Intune MAM and Conditional Access work is an important step toward a more scalable, enterprise-ready AI CardVault ecosystem.

As we continue to enhance the platform, our focus remains on balancing security, flexibility, scalability, and user experience within a unified product architecture.

Final Outcome

Today, AI CardVault supports:

• Intune MAM-enabled enterprise clients
• Non-MAM users
• Multi-client and multi-tenant enterprise configurations
• Conditional Access–driven authentication behavior across iOS and Android

All within a single application.

For us, that is the real value of enterprise-ready architecture: strong security integration without sacrificing product simplicity, deployment flexibility, or long-term scalability.