A Power Pages access rule attached to a localized content page
What it is
Page access rule is attached to one language version, not the page.
Why it matters
Power Pages models a page as one root row plus a content row per language, and access rules are meant to attach to the root because that is where the inheritance walk starts. Attached to a single content row, the restriction holds for that one language and the page's other versions inherit nothing from it.
Easy to miss, because the design studio shows the rule on the page and testing in one language confirms it works. A single-language site has the same configuration defect with no visible symptom today, and it starts mattering the moment a second language is added. This describes rule placement rather than the site's overall protection: the page may also be covered by a correctly placed rule further up its inheritance chain.
Find it yourself
Power Pages design studio, open the page and check whether the access control rule sits on the root page or on a language version beneath it. Verify by opening each language version from a private browser window with no session and confirming they all behave the same way.
How to fix it
Move the rule onto the root page so every language version inherits it. Where one language genuinely needs different protection, keep it where it is and record why.
No control mapping, deliberately
This is a security finding that carries no SOC 2, ISO 27001, NIST 800-53 or CMMC reference. That is a decision rather than an omission. Pathix maps a finding to a control only where the mapping is defensible to an assessor, and a stretched one would undermine every mapping that is real.
Pathix checks this across every environment you scan, along with 71 other conditions. Self-hosted in your own Azure, read-only, metadata-only.