# How to implement secondary login for specific tasks **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [January 22, 2026, 5:01pm UTC](https://forum.inductiveautomation.com/t/how-to-implement-secondary-login-for-specific-tasks/113488 "2026-01-22T17:01:18Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\ **Post date:** [January 22, 2026, 5:01pm UTC](https://forum.inductiveautomation.com/t/how-to-implement-secondary-login-for-specific-tasks/113488/1 "2026-01-22T17:01:18Z")
We use an external IDP for the main login for operators to access perspective and they have various roles tagged to their accounts based on operators, supervisor, admin, etc. This gives them access for who can change what set points and such but now there's an additional ask for allowing additional bypasses only during certain activities after the user has provided an additional login for that access for lets call it maintenance mode. So I'm wondering how to implement this. Can Ignition support a secondary local account login within Perspective? Or is there a better implementation for giving them access to a subset of buttons only some of the time. Our safety procedures prevent us from having these buttons available all the time and relying on operators solely following procedural controls. So far the backup plan is to have them have second email accounts as super users but that's more effort on the account management side and it'd be nice to keep it within Perspective. 8.1.49 ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [January 22, 2026, 5:05pm UTC](https://forum.inductiveautomation.com/t/how-to-implement-secondary-login-for-specific-tasks/113488/2 "2026-01-22T17:05:52Z")
The built in authentication challenge might be enough for your use case, but it would require a login operation for each action taken that is locked behind the higher access. > **[Authentication Challenge Action​ - Component Events and Actions | Ignition User...](https://www.docs.inductiveautomation.com/docs/8.1/ignition-modules/perspective/working-with-perspective-components/component-events-and-actions#authentication-challenge-action)** > > In Perspective, events and actions are some of the fundamental building blocks of project functionality. Actions give you the ability to respond to specific user inputs (such as mouse, keyboard, and touch inputs), as well as broad session events... > **[system.perspective.authenticationChallenge | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-perspective/system-perspective-authenticationChallenge)** > > Triggers an authentication challenge action. > **[Authentication Challenge​ - Perspective Session Event Scripts | Ignition User...](https://www.docs.inductiveautomation.com/docs/8.1/ignition-modules/perspective/scripting-in-perspective/perspective-session-events-scripts#authentication-challenge)** > > Perspective offers a collection of Session Events designed to allow the Gateway to track and interact with the Session at critical moments. Specifically, they are scripts that run in the Gateway when a Session starts up, shuts down, or runs a... ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 22, 2026, 5:19pm UTC](https://forum.inductiveautomation.com/t/how-to-implement-secondary-login-for-specific-tasks/113488/3 "2026-01-22T17:19:29Z")
If you use the Auth Challenge functionality (and I think it **is** your answer), it is up to you to include scripting that logs the relevant time stamps and roles in session properties, and expires on some desired time criteria. (Unless you want to challenge for every operation.) ---
**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\ **Post date:** [January 22, 2026, 5:33pm UTC](https://forum.inductiveautomation.com/t/how-to-implement-secondary-login-for-specific-tasks/113488/4 "2026-01-22T17:33:58Z")
Thanks, that's exactly what I was missing. And yeah we already have audit logs recording every action already and the existing soft bypasses have timers in the PLC that auto turn off unless they extend the duration so should be set on the safety side adding these and using the same format. Just needed a way to ensure they cant be accidently clicked without additional hoops. ---
**Author:** ![SWoollett](https://avatars.discourse-cdn.com/v4/letter/s/a9a28c/32.png) [@SWoollett](https://forum.inductiveautomation.com/u/SWoollett)\ **Post date:** [January 23, 2026, 8:05pm UTC](https://forum.inductiveautomation.com/t/how-to-implement-secondary-login-for-specific-tasks/113488/5 "2026-01-23T20:05:13Z")
We have implemented a similar system where we use the authentication challenge to set a session prop, which requires the same user to be logged in to complete the Authentication challenge. The session prop is used in the ‘enabled’ prop to enable the selections which require elevation. So regardless of what level account executes the authentication challenge, everything will be enabled but ultimately we are still using the baked in tag security to limit access to the lower levels. This just prevents using that field to edit the tag The session prop is setup to revert after some defined time. This is a pretty straight forward implementation, but does mean you have to set up every element which requires elevation which could result in it being missed. I’m currently contemplating an alternate solution which actually alters the sessions security so it is baked into every element by default