Landing-page rules control the default starting point after login or when users click Home, but they do not override deep links or change underlying authorisation. That means they influence user experience and workflow entry, while permissions still govern what the user can actually do once inside the platform.
How landing-page rules and direct access control work at different layers
Landing-page rules set the default destination after authentication, or the page shown when a user clicks Home. Direct access control decides whether the user can reach a specific resource or perform a specific action at all. The two can feel related in the UI, but they operate at different layers of the platform and answer different questions.
A landing page is navigation logic. It influences where a user starts, what they see first, and how quickly they get to common tasks. Direct access control is authorisation logic. It governs whether the request itself is allowed, regardless of where the user arrived from or which page they used as an entry point.
The practical distinction matters because teams sometimes infer too much from the landing experience. A user who lands on an admin dashboard does not necessarily have admin permissions, and a user blocked from a menu item may still reach a deep link if they are entitled to the underlying resource. The real control point is the permission check that fires on the target object or action, not the default page.
Why deep links and underlying permissions are not the same thing
Deep links bypass the normal starting page and go straight to a specific route, record, or function. If the platform is designed correctly, that shortcut should not change authorisation outcomes. The same permission model must apply whether the user starts from Home, a bookmark, a notification, or an embedded link. Good navigation rules help people move efficiently, but they do not substitute for access enforcement.
This separation is important in systems where menus are customised by role, business unit, or tenant. Hiding a page in the landing experience can reduce clutter, but it does not secure the target. Likewise, sending everyone to a “safe” default page does not prevent an authorised user from reaching a more sensitive area if their role allows it.
When readers ask whether landing-page rules “override” access control, the answer is no. A landing page can shape the first click, but it cannot safely replace object-level or function-level checks. If the underlying authorisation model is weak, the user experience layer only masks the problem.
What practitioners should verify when both controls exist
Start by checking whether the product treats the landing page as presentation logic or as a policy decision. The correct pattern is presentation first, authorisation second: the page may steer the session, but each protected endpoint still enforces its own access decision. That is especially important in portals, consoles, and SaaS products where one user can reach many resources from a single shell.
It also helps to separate “can the user see the entry point?” from “can the user complete the action?”. Those are not the same control. A user may see a tile, route, or dashboard card because it improves discoverability, while the backend still rejects the request when the user lacks permission. In a well-designed system, the visible shell is not the security boundary.
For teams designing or reviewing the control model, the safest test is simple: if you remove the landing rule, does the permission decision change? If the answer is no, the landing rule is only a routing preference. If the answer is yes, the implementation is probably mixing UX and authorisation in a way that deserves review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Direct access control depends on enforcing permission decisions at the target resource. |
| AC-6 — Least Privilege | The answer contrasts routing convenience with the permissions that actually limit action scope. | |
| Recommendation — Enforce AC-3 at each protected object or action, not at the landing page alone. Apply AC-6 so users can reach only the resources and actions their role requires. | ||
| OWASP ASVS | V8 — Authorization | The question is about whether access is granted by the page shown or by the underlying authorisation check. |
| Recommendation — Verify V8 checks on every protected route and action, regardless of entry path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Landing pages and direct access both sit under the broader requirement to control access to information and functions. |
| A.8.5 — Secure authentication | The landing page only appears after login, so authentication remains separate from the authorisation decision. | |
| Recommendation — Define and enforce access control rules independently of UI landing behaviour. Ensure authentication succeeds before any routing logic is applied. | ||
Practitioner Guidance
What to verify: Confirm that the landing page only changes the default starting view and does not grant access to hidden routes, APIs, or actions. Test with a deep link, not just the Home page, because that is where weak designs often show up.
Common mistake: Treating menu visibility or homepage placement as evidence of permission. That assumption breaks as soon as a user opens a bookmark, refreshes a page, or follows a direct link.
Decision rule: If the control affects where the user starts, treat it as navigation. If it affects whether the user can read, write, approve, or administer a resource, treat it as authorisation and validate it at the target.
Practitioner takeaway: Landing-page rules can improve usability, but they should never be relied on to enforce access. The security decision belongs to the underlying permission check, not the first screen the user sees.