One account. Too many access rights?

No. Central sign-in simplifies identity, but it does not replace checking permissions in the target systems.

That depends on session management and the integration options of the applications. We check these limits and document remaining time windows and measures.

Employees should sign in with access that matches their role and should not keep unnecessary rights when their role changes. We connect enterprise systems to your identity management, set up single sign-on and automate the lifecycle of accounts and access rights.

Permission concept with roles per system and segregation of duties Single sign-on via SAML and OpenID Connect for ERP, CRM, intranet and workflows Multi-factor authentication with FIDO2 and conditional access Automated user management via SCIM from the HR system Recertification of permissions and logging for audits

Permission concept with segregation of duties Connected systems with SSO and MFA Recertification process with audit log

Single sign-on answers who is signing in. What that person is allowed to do in an ERP or CRM must additionally be governed by the respective permission model. We record roles, privileged activities and necessary segregation of duties. Supported applications are connected through SAML or OpenID Connect. Multi-factor methods and access conditions are set according to protection needs. Existing local emergency accounts need to be handled in a documented, controlled way.

The system of record for HR data supplies events for account creation, role changes and offboarding. Provisioning can use SCIM or supported connectors; not every target system supports the same functions. We test deactivation, group changes and the handling of existing sessions. When transfers fail, discrepancies must become visible. Regular reviews confirm which rights are still needed, instead of letting group memberships accumulate indefinitely.

Acceptance testing includes positive and negative access tests with different roles. We also test an outage of the identity service and the agreed emergency access. The documentation defines who is responsible for business approvals and technical administration. An application list, existing roles and typical onboarding, role change and offboarding cases are helpful.

Processes, system landscape, data quality Business units, IT, data protection, OTOKO® Process Consultant Process map, system inventory, data quality report, prioritized fields of action

Target processes, architecture, integration plan Business units, architecture, information security Target processes, system architecture, interface register, permission concept

One process or site in production OTOKO® consultants, key users, your IT Pilot with real data, feedback from key users, decision on rollout

Configuration, interfaces, migration, training OTOKO® consultants and developers, key users, your IT Configured system, interfaces, migrated data, training, acceptance

Monitoring, releases, support OTOKO® operations or your team Monitoring, release planning, support, annual permission review

Target processes, requirements, key user alignment

System architecture, interfaces, data ownership