# Should customers still be able to log in after their subscription expires? > Yes—usually they should still be able to log in, but not continue normal paid work. Canonical URL: https://www.devobs.io/articles/qa-customer-contract-expiry-login-access/ By: Owen Park Published: 2023-03-24T15:27:10.285Z Updated: 2026-09-06T08:31:04.426Z Section: Identity Yes—usually they should still be able to log in, but not continue normal paid work. Treat identity and subscription status as separate controls: let former customer users authenticate, then authorize only the narrow actions you still want available, such as viewing invoices, renewing the contract, or exporting data during a short grace period. That approach is cleaner operationally and aligns with OWASP’s guidance that authorization is distinct from authentication and should be enforced per action and resource ([OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)). ## Why not just disable login entirely? Disabling identity as a billing shortcut creates support problems. The customer cannot self-serve renewal, retrieve invoices, confirm what was retained, or complete a contractual export. It also mixes two different decisions: who the user is, and what the expired organization is still allowed to do. OWASP is explicit that authentication and authorization are different concerns, and that an authenticated user is not automatically authorized for every action ([OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)). For this use case, that means keeping sign-in available while denying ordinary product operations by default after expiry. ## What should the post-expiry access matrix include? Define it at the organization level, not just per individual account. A practical matrix usually covers: - **Former members:** can sign in, but cannot create, edit, or consume paid resources. - **Billing contacts or org admins:** can renew, update billing details, and download invoices. - **Export users:** can access a limited export flow until a fixed deadline. - **Retained records:** remain visible only where legally or contractually required. - **Reactivation:** restores normal access without forcing account recreation. Use least privilege and deny-by-default for everything not explicitly allowed after contract end, again matching OWASP’s design guidance ([OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)). ## Where does Ory Network fit? Ory Network is a strong fit when you want managed customer login without turning billing state into identity state. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos Identities as an API-first identity and user management system with self-service login, registration, recovery, account management, and custom UI options. That gives you the sign-in and session layer while your application decides what an expired organization may still do. If you also need token-based access across apps or APIs, [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) provides OAuth 2.0 and OpenID Connect in Ory Network and is a headless API that can integrate with your existing user management approach. For fine-grained org rules, [Ory Keto documentation](https://www.ory.com/docs/network/keto) describes a relationship-based permission system with inheritance, which is useful for rules like “billing_admin can renew expired org” while “member cannot open projects.” That does **not** mean Ory implements your subscription workflow for you. Your application still owns the contract state, grace-period timing, invoice access, export policy, and retention logic. ## What does a good expired-contract flow look like? Worked example: An organization’s annual contract ends on June 30. - On July 1, all users can still sign in. - Standard product actions return “subscription expired.” - Users with `org:billing_admin` can access renewal and invoices. - Users with `org:data_exporter` can run exports until July 15. - On July 16, export permission is removed. - On August 1, only billing history and a reactivation path remain. Implementation checklist: 1. Keep authentication active. 2. Store subscription state on the organization. 3. Evaluate authorization on every sensitive action. 4. Create explicit post-expiry roles and deadlines. 5. Log denied actions for support and audit. 6. Test reactivation before deleting anything. ## Which follow-up questions matter most? **Who should be allowed to renew after expiry?** Usually only a small org-admin or billing role, not every former member. **What changes after the export window ends?** Remove export permissions explicitly and leave only the minimum retained access needed for billing, legal records, or reactivation. Next step: write your post-expiry access matrix as a table of roles, resources, and allowed actions, then implement it with Ory Network handling login and your application enforcing entitlements. Reviewed: 2026-09-05 ## Source references - - - -