Access is a decision.
Keep it deliberate.

1. The owner opens the door.

First-time access must be initiated by the site owner or an authorised administrator. Each invited person receives an individual grant tied to that site.

• No public application form for access to arbitrary WordPress websites.
• Renewal is reserved for verified identities with a previous approved grant on that same site, subject to owner policy.
• Email verification establishes control of an inbox. It does not approve access.
• Pending requests leave existing restrictions in place. Bans take precedence over otherwise valid grants.

2. Login and recovery need equal care.

The implementation plan uses short-lived, single-use sign-in challenges with hashed stored tokens, request throttling and a deliberate confirmation step before consuming a link.

• Mail scanners should not consume an invitation before the person opens it.
• Personal access history, block reasons and unblock dates should appear only after identity verification.
• Authenticator setup, recovery codes and owner-assisted resets need explicit rules and an audit record.
• A second email to the same inbox is not independent two-factor protection. Stronger authentication options require their own assessment.
• Sign-in secrets must stay out of activity logs and analytics.

The landing page has no production login, account creation or access-recovery endpoint. Its interactive examples stay in the browser and use sample data.

3. Permissions and time limits travel together.

Access should be limited to the work approved and the period approved. A fresh sign-in link must not extend that period.

• Use limited default roles and display permissions before approval.
• Enforce supported restrictions in backend actions and API routes; hidden navigation alone is not access control.
• Check grant state and expiry during authenticated requests. Scheduled cleanup is not sufficient by itself.
• Pause, revoke, expiry and bans must end relevant temporary sessions.
• Cover alternate authentication routes and persistent credentials so a temporary identity does not silently become permanent.
• Closure should preserve the person's work while ending their access.

4. Useful evidence, with limits on collection.

The proposed timeline records supported changes and access events, with timestamps, actor information and relevant session context. Coverage must be documented for each integration.

• Restrict who can view and export records.
• Let the owner configure how long records are retained.
• Do not record passwords, raw login tokens, authenticator secrets or sensitive request bodies.
• Keep grant closure separate from log deletion.
• Enterprise external-log delivery should report failures and gaps, with retry behaviour.

This is an activity record, not screen recording or a complete account of everything done on a server.

5. Be honest about the boundary.

Full WordPress administrator access can permit installation or execution of server code. A plugin running in that same installation cannot promise dependable isolation from someone allowed to run arbitrary code.

Higher-assurance deployments may need hosting controls, staging environments, restricted code deployment and independently retained logs. Revoking a session does not undo earlier changes or remove access created through another route.

TempLogin is not ISO 27001 certified. Proposed approvals and evidence features may support an organisation's processes; they do not establish certification of its information security management system.

6. What needs to happen before release.

• Implement and test authentication, permissions, session termination and the complete access-state lifecycle.
• Review token handling, recovery, request abuse, privilege escalation and alternate authentication routes.
• Test supported WordPress/PHP versions, hosting environments, multisite and selected integrations.
• Document activity coverage, data handling, retention defaults and known limitations.
• Perform a security review appropriate to an access-control product before a production release.

Questions about the design?

Contact Ademola to discuss the approach. Do not send passwords, login links or other credentials through a general contact form.

Reference guidance

WordPress hardening · OWASP authentication · OWASP logging · NIST authenticators · ISO/IEC 27001 overview