Share Support Access Without Sharing Your Own Password
A support task often needs more than a screenshot but less than a permanent administrator relationship. Giving a contractor your own password makes it harder to separate their access from yours, while creating an ordinary long-lived account adds another credential to remember after the work is finished. Temporary Login provides an administrator-issued invitation with an explicit lifetime and a controlled session. The recipient opens the link, and the module checks the invitation before establishing the associated WordPress login.
This is distinct from Magic Login, where eligible users request their own short-lived sign-in email. Temporary Login begins with an administrator deciding who should receive access, what session role they need, and when that access should end. It is intended for collaboration and support rather than public account login. The link is still a credential: share it only with its intended recipient, and use the available restrictions rather than treating possession of the URL as harmless information.
Separate the Temporary Session Role From the Underlying Account
An invitation can use an existing WordPress account, or the administrator can enter an email address to create a new one. A newly created account is stored as a Subscriber; the invitation's Role selection is an overlay for the temporary session. This lets an administrator grant the session the access needed for the task without permanently assigning that role to the new user's normal account record. The session and invitation remain associated on the server so their access can be managed together.
The role selector starts at Administrator, which is an important choice to review rather than accept automatically. Select the access level that fits the actual work, and remember that a temporary administrator is still subject to the module's additional restrictions. Accounts flagged as passwordless-only cannot use normal password login or password reset, so those invitation accounts are not given a durable password route as an alternative to the link. That restriction applies to flagged accounts, not a blanket conversion of every existing user into a passwordless account.
Set an Expiry and Bound How an Invitation Can Be Used
Every invitation should have a lifetime appropriate to the support task. Temporary Login offers predefined durations and a custom expiry option for licensed workflows, while unlicensed creation and updates are constrained to one-day access. Expiry and revocation are checked when the token is presented, along with the configured usage and access restrictions. This turns the invitation into a managed access record rather than an ordinary link that remains useful until somebody remembers to delete a user.
Pro adds single-use invitations, a maximum-use value, IP or CIDR restrictions, and binding to the first user-agent. A maximum-use value of zero means unlimited uses within the invitation's other limits, not an invitation with no expiry. User-agent binding is a matching restriction, not proof of a physical device's identity. Each browser must use the token and establish its own bound session; the module does not provide one transferable login cookie that silently authorizes every browser opening the site.
Allow Necessary Work While Keeping Sensitive Controls Restricted
A temporary session can receive useful administrative access without receiving every powerful tool available to a permanent administrator. When its session role can manage plugins or themes, extra checkboxes control supported install/activate and deactivate/delete permissions. WP PowerSuite itself cannot be removed through the temporary session. These controls let an owner allow the operations needed for a specific support request instead of automatically exposing the entire plugin and theme administration workflow.
Some areas remain blocked regardless of those choices. These include plugin and theme source-file editors, core updates, import/export, Site Health, Temporary Login administration, and the PowerSuite License page. Sensitive registration and account-default options are protected as well. Code Snippet, WP Config Editor, Header & Footer Code, and Quick Debug tools remain unavailable through the temporary session. These are concrete restrictions, not a claim that the session is a sandbox or that all permitted changes are harmless: authorized content or configuration changes are not automatically rolled back when access ends.
Bind the WordPress Session to the Invitation
Temporary Login does more than accept a token and forget where the resulting session came from. Its signed session cookie and server-side mapping connect the WordPress authentication token to the invitation record. That relationship supports invitation checks and the module's session-management behavior instead of relying only on a browser remembering that it once opened a valid URL. The invitation remains the source of the temporary access policy, with its expiry, revocation state, usage limits, and licensed restrictions.
Disabling the module revokes its invitation rows, advances the session version, destroys bound sessions, and clears its cookie. It is therefore not a neutral pause that leaves every temporary session running independently. Administrators can also manage individual invitations from the dedicated screen rather than disabling the entire feature whenever one collaboration finishes. Keeping the link and the session connected makes it easier to treat temporary access as something with a defined lifecycle, not just another account that happens to have an expiry written in a note.
Review Invitations and Keep a Record of Support Access
The dedicated Temporary Login screen separates all, active, expired, and revoked invitations and supports bulk revocation or deletion. After creation, administrators can copy the link, choose an optional post-login destination, and use the email helper to notify the recipient. A Users-table indicator identifies temporary-login accounts, while the activity modal and CSV export provide visibility into the invitation's recorded activity. The module retains its own activity records for 90 days rather than depending on a separate general-purpose audit table.
Successful token authentication also exposes the event used by Admin Login Alerts for qualifying administrative notifications when that module is configured. This can help an owner notice when an invited support session begins, while the invitation screen remains the place to manage its status and restrictions. Notifications and activity records support oversight, but they are not a recording of every visual action a collaborator takes. Review the available event detail rather than presenting the log as a complete screen replay.
Understand the 2FA and Session-Management Exceptions
Temporary Login uses a different authentication policy from a normal password sign-in. Its token flow bypasses PowerSuite 2FA. That behavior should be considered when deciding who receives a link, which session role it carries, and whether licensed IP, use-count, or user-agent restrictions are needed. Do not assume an administrator-role invitation will receive the ordinary account's second-factor challenge after the token is accepted. The invitation itself is the access credential for this workflow.
The module also prevents chaining temporary access into an impersonation session: Login as User is blocked while the Temporary Session Guard is active. Meanwhile, Login Session Manager excludes temporary sessions from its ordinary concurrency limits so a support invitation is not unexpectedly ended by a standard role cap. These are intentional integration rules. Temporary access remains governed by its own invitation controls rather than being treated as an unrestricted version of normal account login.
