# Role-Based Access for Employees and Contractors Cybersecurity | MT BYTES solution study Application-level access controls connect employee and contractor roles to sign-in, privileged work and account removal, with reviewable permissions and recovery paths. The access system assigns permissions to the application tasks performed by employees, contractors and service identities. Sign-in, role changes, privileged access and account removal follow distinct controls with named owners. Temporary elevated permissions have defined limits. Review and recovery procedures check both authorized work and refused actions, including applications outside the primary directory. ## Solution design ### Permissions match the work being done Employees and contractors receive access to specific applications and actions, with an owner and reason behind each entitlement. Administrative access is temporary where practical. Account changes include checks for local credentials, active sessions and integrations that need separate handling. - Application permissions tied to actual responsibilities - Temporary access with a sponsor and expiry - Departures checked across central and local accounts **Business context:** A technology company with distributed employees, external specialists and a mixture of hosted and internal applications **Core capability:** Cybersecurity ![Solution study artwork](../../images/solution-studies/selected/23-hero.webp) ## Scope - Application, account and permission inventory - Role and application access rules - Employee and contractor lifecycle workflows - Privileged access and service identities - Legacy-system and emergency access procedures ## Different jobs, different permissions Access to the company network does not explain what someone should be able to do inside an application. Reading an account, exporting a customer list and changing a production setting carry different responsibilities. Contractors add another variable: their work may end while their account remains active. The access model makes those differences explicit at the resource being requested. Identity establishes the requester; application permissions determine the permitted action. Device context adds another check where the business can evaluate it reliably. Staff retain a straightforward sign-in experience without receiving broad access merely because that sign-in succeeds. ## The accounts outside the directory The inventory lists each application's owner, authentication method, privileged roles, contractor accounts and machine identities. It also records direct server access, shared credentials and tools with local accounts. These routes matter because removing someone from the central directory may leave other access unchanged. Permissions are reviewed against tasks. A support specialist can inspect an account without downloading the whole customer database. An engineer can request production access for a specific investigation. The review identifies routine permissions, permissions needing approval and combinations of authority that the business wants to keep separate. ## Checks at the application boundary Applications use the central identity provider where they support it. Authorization remains specific to the application, gateway or infrastructure resource. Access rules include the requested role and action, with additional checks for sensitive administration. A successful authentication cannot override a restriction on exporting data or changing configuration. Legacy applications use a controlled entry route when they cannot support the same checks directly. Their local accounts and remaining limitations stay in the inventory. Device requirements are introduced only where support staff can explain and troubleshoot them. An unreliable device signal should not become an unexplained barrier to essential work. ## Joining, changing teams and leaving A new account has an approved sponsor, role and initial application access. Additional permissions go to the application owner for review. Contractor access includes an expiry. The request records the reason, so a later reviewer can distinguish access still needed for active work from an old entitlement nobody remembers granting. A transfer removes obsolete permissions as it adds new ones. Departure checks cover active sessions, local accounts, shared secrets and any service responsibilities held by the person. Separate system actions appear as tasks with owners and completion status. The account is not considered fully removed while an outstanding local-access task remains unexplained. ## Short-lived privilege and independent service accounts Administrative work uses a separate role with an activation or approval process appropriate to the service. Access is limited to the necessary resource and duration. The record includes who requested it, who approved it and the actions available during the session, giving reviewers something more useful than a list of permanent administrators. Integrations use identities owned by the service rather than credentials borrowed from an employee. Each has a purpose, required permissions and a replacement procedure. This prevents a departing engineer's account removal from unexpectedly stopping a business integration and makes machine access part of the same ownership review. ## When normal sign-in is unavailable An identity-provider interruption or failed device check can block legitimate work. Emergency procedures identify who can authorize temporary access, which systems it covers and how the access is removed afterwards. Staff have a clear escalation route instead of sharing a working account to get past the problem. Emergency credentials are restricted and their use is recorded. Controlled exercises check that the route still works without leaving it active for routine use. Legacy exceptions receive a responsible owner and review date. A recurring exception prompts a fix to the application or policy, rather than becoming an undocumented permanent bypass. ## Application-by-application cutover The first group of applications has understood account ownership and representative users. Where supported, observation or limited enforcement reveals legitimate workflows affected by a policy before wider rollout. Feedback records the failed task and its cause, including confusing prompts, unsupported devices and incorrect roles. The remaining applications follow risk, readiness and support capacity. Sensitive systems receive a rehearsed cutover and a recovery route. Each migration checks that previous access paths are retired or controlled. Help-desk guidance describes the changes users will encounter and the information needed to investigate a blocked request. ## The application owner approves the entitlement The identity team maintains sign-in and shared policy services. Application owners decide which responsibilities justify access to their systems. Security reviews sensitive permissions and exceptions. People operations supplies reliable joining, transfer and departure information. Those responsibilities keep access decisions close to the people who understand the work. Periodic reviews focus on dormant accounts, accumulated privileges, expired sponsorship and services without an owner. Reviewers see the reason and history for each permission. Policy changes follow a tested release process, with support feedback used to address unnecessary friction before users develop informal workarounds. ## Allowed tasks and refused actions Verification includes both sides of a permission rule. An approved support user should read the required account information and be refused an unauthorized export. An engineer's temporary access should expire as specified. These checks examine the resource and action, not simply whether the user can sign in. Lifecycle exercises follow an account across central and exceptional systems. Outstanding revocations remain visible until resolved. Administrative and machine access are reviewed for current purpose, scope and ownership. Together, these checks show whether the permissions staff receive still match the work the business expects them to do. ## Operational flow 1. **Inventory accounts and access.** Record applications, local access, privileged roles and service identities. 2. **Define role-specific permissions.** Translate job responsibilities into allowed application actions. 3. **Migrate each application.** Introduce policy with representative users, support guidance and recovery steps. 4. **Process staff access changes.** Apply joining, transfer and departure decisions across all recorded access routes. 5. **Review permissions and exceptions.** Check sponsorship, temporary privilege and legacy access that still needs attention. ## Key decisions ### Permissions at the resource Check application actions separately from successful sign-in. The same person can legitimately read a record without being authorized to export or alter it. ### Visible legacy exceptions Inventory local accounts and protect applications that cannot use central controls. Access removal is incomplete when an old route remains outside the review. ### Separate integration identities Give each service its own credentials and accountable owner. A staffing change should not unexpectedly disable an unrelated business process. ## Evaluation measures These measures define the evaluation criteria for the workflow, its controls and the quality of completed tasks. ### Application permissions **Measure:** Exercise approved tasks and prohibited actions for representative roles. **Success criteria:** Users can complete their work within the agreed access boundary. ### Access removal **Measure:** Trace departure and transfer events through central and local accounts. **Success criteria:** Obsolete permissions are removed and unresolved actions have an owner. ### Privileged access **Measure:** Review elevated sessions and service identities against their purpose and expiry. **Success criteria:** Sensitive access has a current reason, limited scope and accountable owner. ## In practice An access record needs to explain why the permission exists and what should end it. Application owners, staff changes and temporary privileges all feed that record. When someone moves or leaves, the removal checks extend beyond the directory to the local accounts and service dependencies that might otherwise remain unnoticed.