Solutions
A new colleague appears in your HR system or Google Workspace? MIA detects their role, assigns the matching application kit and creates their SaaS accounts. Onboarding happens without tickets, missed steps or excessive rights, whether you use SSO or not.
Hosted in France
No mandatory SSO
~90 connectors + SCIM 2.0
Camille Martin
New starter · Google Workspace
Role: Sales
Sales kit · 5 applications
✓ Every action is recorded in the access log
Hébergé chez OVHcloud, Strasbourg
Sans IdP ni SSO imposé
OAuth 2.1 · OpenID Connect · JWT
Automatic provisioning creates employee accounts and grants the right permissions across your business applications without manual setup. A new hire or a change of role triggers rules defined for that role. Deprovisioning applies the same discipline when someone leaves.
With MIA, you choose your source of truth and keep your existing authentication architecture. No new identity provider or SSO is required.
New arrival in the source of truth
Role → application connector kit
About 90 connectors and SCIM 2.0
Tamper-evident access log
Manual setup creates three recurring problems whenever a new employee joins.
New employees spend their first days asking for tools. Tickets pile up.
An existing profile becomes the template, including unnecessary inherited access.
Accounts created across separate consoles leave a fragmented audit trail.
Configure the workflow once. MIA then applies the right rules each time someone joins.
Connect your HR system, Google Workspace or Microsoft 365. Your existing IdP stays in place.
Map each job to its applications and the required permission level.
When a user is added, MIA detects their role and creates accounts across the kit.
Check each application status, handle failures and find every decision in the access log.
Roles, external profiles and traceability make every new hire easier to manage.
Instead of selecting ten applications for every new hire, define what each role needs once. MIA applies the rule to every employee, keeping access consistent and limited to what is necessary.
• Detect the role automatically from your source of truth.
• Define the permission level for each application.
• Combine a shared foundation with role-specific kits.
• Update access when an employee changes role.
Core + roleCore + roleEnds on 31/03Access limited to the assignment scope and revoked at the end date.
In a growing company, external identities can account for a large share of users. MIA provisions them with the same discipline as employees and with additional safeguards.
• Dedicated kits for employees, interns and contractors.
• An access end date for short assignments.
• Additional access requests approved by a manager.
• Applications outside SSO handled through connectors.
SAEmployees · Core + role kit 142PRContractors · End date required 38ALApprentices · Restricted kit 93 external accesses expire this week
Provisioning feeds directly into MIA’s access log. You can see who received each permission, when, under which rule and whether an operation failed.
• Filter history by application, user, event type and date.
• Export CSV evidence for audits and security reviews.
• Verify the integrity of the sealed access log.
09:02 Camille Martin detected in Google Workspace · Sales role09:03 Sales kit applied · 5 applications09:04 HubSpot account created · Sales Pro licence09:05 Lemlist account created · user role02:00 Daily seal · block no. 312SSO makes sign-in easier. A provisioning workflow grants the right access for each role, then removes permissions when they are no longer needed.
About 90 dedicated connectors, each documented step by step, plus a generic SCIM 2.0 connector for any compatible application.
Access is ready from day one, permissions match each role, and every decision is traceable for audits. Automation helps every team.
Define access kits once, then handle fewer setup tickets for every new hire.
Apply least privilege from day one and keep a record of every decision.
Match licences to real roles and needs, and avoid forgotten accounts.
MIA works with the identity source you choose and orchestrates provisioning around your current architecture. Service data is hosted in France by OVHcloud.
It creates accounts and grants the permissions a person needs based on their role, using rules defined in advance. Role changes and departures can follow the same lifecycle.
No. MIA works with your existing source of truth and authentication architecture. It does not impose an IdP or SSO.
You map each role to an application kit and permission levels. MIA applies the kit when the person joins, then tracks exceptions and approvals.
Yes. Dedicated kits can limit the scope and duration of external access. Deprovisioning helps remove permissions when someone leaves.
The log records account creations, changes, and decisions. You can filter and export the history to prepare your controls.
SSO simplifies sign-in with one identity. Provisioning creates accounts and grants permissions in each application. Without provisioning, those accounts still need to be created, changed, and removed manually.
