Access management: roles, lifecycle and costs
Access management connects technical accounts with business responsibilities. A successful login does not authorise every action. Specify users, systems and processes to compare equivalent work. Start with important access and test actions that should be refused as well as permitted.
Separate authentication from authorisation
Central sign-in can simplify access to multiple applications. Permission to read or change data still depends on each application’s access model. Examine both layers and existing local accounts.
State whether you need implementation, extension, cleanup or ongoing operation. Reviewing the existing setup and implementing a new one require different deliverables.
Build roles around tasks and responsibility
Map required access to tasks and resources. Groups can simplify administration without accumulating unnecessary rights. Some important decisions may need separate approval.
| Access type | Clarify in the role model |
|---|---|
| Employees | Tasks, permitted actions and data areas |
| External users / guests | Responsible owner and access end date |
| Administration | Privileges, approval and logging |
| Technical accounts | Purpose and accountable owner |
Define joining, moving and leaving
Specify who requests and approves access, where workforce information originates and when changes take effect. A role change should not automatically retain old rights alongside new ones.
Test departures, expiring guests and failed synchronisation. Blocking a central account does not necessarily remove every local permission or active session. Document exceptions and manual follow-up.
Check connections and existing accounts
Separate applications, directories, file access and remote access. Supported sign-in and automatic account provisioning are different capabilities. Check the actual interface, edition and configuration.
A pilot should cover creation, change, removal and errors. Avoid uncontrolled simultaneous changes. Agree rollback, responsibility and handling of applications without a suitable interface.
Combine sign-in protection with rights review
Multiple factors can protect authentication without replacing appropriately limited rights. For administration, consider separate accounts, temporary approval and a traceable process.
Decide who reconfirms rights and responds to anomalies. Logs need relevant coverage and active review. Emergency access also needs an owner, protection and documented use.
Compare users, connections and operation together
Licensing, role design, connections, account cleanup and rollout contribute to costs. Some capabilities depend on edition. Compare the actual users and required functions over the same period.
Include support, recurring reviews and later changes. Automation still requires approval owners and exception handling. Agree configuration export and handover on a provider change.
| Cost item | Specify in the quote |
|---|---|
| Licensing | Users, guests and required capabilities |
| Setup | Roles, rules and approvals |
| Connections | Systems, account synchronisation and errors |
| Rollout | Pilot, training and phased transition |
| Operation | Reviews, support, changes and exit |
Start with verifiable examples
Prepare user numbers, systems and desired controls. The initial enquiry needs no passwords, named account lists or detailed permission exports. Exchange those later through an agreed secure channel.
Agree acceptance criteria: correct access on joining, updated rights on moving, removal on leaving and refusal of unauthorised actions. Document the pilot and assign owners for ongoing operation.
Frequently asked questions
Is central sign-in sufficient?
It simplifies authentication without automatically governing every action in every application. Both layers need checking.
Can existing systems remain?
Integration is often possible. Interfaces, editions and existing accounts determine the work; supported capabilities differ.
Does everyone need the same rights?
No. Access should follow tasks and responsibilities. Administrative privileges need separate consideration.
Are multiple factors sufficient?
They protect authentication, but do not replace suitable permissions or processes for changes and departures.
How should guests be managed?
Define an owner, duration and removal process. Reviews help identify access that is no longer needed.
What belongs in the initial enquiry?
User numbers, system types, required controls and a short objective. No secret credentials or named permission exports.
