Access Control & Least Privilege

This page describes how Prodia governs access to its platform, customer data, production infrastructure and corporate systems. The objective is simple: every identity — human, service or machine — receives the minimum access necessary to perform a defined function, for the minimum period necessary, and every privileged action leaves an auditable trail. Access control is treated as a continuously enforced control surface, not a one-time provisioning event.

1. Guiding principles

• Least privilege by default. No identity receives standing access to production data or systems. Default posture is zero access; grants are explicit, scoped and time-bound.
• Deny by default. Policies are written as allow-lists. Anything not explicitly permitted is refused.
• Separation of duties. The person who proposes a change is not the person who approves it; the person who approves a change is not the sole person who can deploy it.
• Auditability. Every authentication, authorization decision and privileged action is logged to tamper-evident storage with sufficient detail to reconstruct who did what, when, from where and why.
• Continuous validation. Access is reviewed on a defined cadence, on role change and on departure. Dormant access is removed automatically.

2. Authentication

2.1 Identity provider

All Prodia personnel authenticate through a single enterprise identity provider with Single Sign-On (SSO). Local accounts on production systems, databases or third-party SaaS are prohibited where the vendor supports SSO. Where SSO is not available, accounts are provisioned individually, recorded in the access register and reviewed on the same cadence as SSO-bound accounts.

2.2 Multi-factor authentication

• Multi-factor authentication (MFA) is mandatory on every Prodia employee account, every administrative interface and every customer-facing console with elevated privilege.
• Privileged roles (production access, secret management, security administration, billing administration) require phishing-resistant factors — WebAuthn / FIDO2 hardware authenticators or platform authenticators bound to a managed device.
• SMS-based factors are not accepted for privileged roles.
• Session length, idle timeout and re-authentication requirements are tightened for privileged sessions.

2.3 Customer authentication

• Customer accounts support email-and-password, social SSO and enterprise SAML/OIDC SSO.
• Customer passwords are stored as salted, memory-hard hashes; plaintext is never logged, persisted or transmitted to internal tooling.
• Passwords are checked against breach corpora; known-breached credentials are refused.
• MFA is available to every customer and is required by default for accounts with administrative or billing scope on enterprise plans.

2.4 Machine and service identity

• Service-to-service authentication uses short-lived credentials issued by the cloud identity provider, scoped to a single workload and a defined set of permissions.
• Long-lived static credentials are prohibited inside the production environment except where a third party offers no alternative; such exceptions are registered, scoped, rotated on a defined cadence and monitored.
• Secrets are stored in an enterprise secret manager; secrets are never committed to source control, never embedded in build artefacts and never shared through chat or email.

3. Authorization

3.1 Role-based and attribute-based access control

Prodia uses role-based access control (RBAC) as the primary authorization model, supplemented by attribute-based controls (ABAC) for sensitive actions where the decision depends on the resource, the request context (location, device posture, time) or the relationship between the identity and the resource (for example, membership of the owning workspace).

3.2 Production and customer-data access

• No engineer holds standing access to production databases or to customer data.
• Production access is requested just-in-time, justified, approved by a second person and granted for a bounded time window.
• Grants are scoped to the narrowest resource that resolves the task (a single workload, a single environment, a single dataset) — never blanket production.
• Sessions are recorded; commands executed during privileged sessions are logged and reviewed.
• Direct writes to production data outside an approved code path are prohibited and alert security on detection.

3.3 Tenant isolation

• Every authorization decision in the platform is scoped to the requesting tenant. Cross-tenant access by customers is not possible through any supported API path.
• Internal tooling that can read across tenants is restricted to a named set of roles, requires elevated authentication and produces an audit record on every access.

4. Role separation

4.1 Separation of duties

Roles are designed so that no single individual can both initiate and approve a sensitive action. The split applies, at minimum, to:

• Code changes — proposed by an engineer, reviewed and approved by a different engineer; merges to protected branches require approval.
• Production deployment — deployment is performed by an automated pipeline against a reviewed, signed artefact; manual deploys require a documented justification and a second approver.
• Access grants — requested by the individual needing access, approved by their manager or system owner, recorded by the identity provider.
• Financial actions — payment provisioning, refund issuance and material spend require a second approver.
• Security-sensitive changes — changes to authentication, authorization, cryptography, data export paths or audit-log pipelines require two-person review.

4.2 Functional separation

• Development, security, operations and approval functions are organisationally distinct.
• The team that develops a control is not the team that audits it.
• Production credentials issued to developers for debugging never carry approval authority for the same change path.

4.3 Administrative roles

• Administrative roles (security admin, identity admin, billing admin, super-admin) are held by the smallest number of named individuals consistent with operational resilience.
• Every administrative role has at least two holders to avoid single points of failure, and no more holders than the role genuinely requires.
• Administrative actions trigger heightened logging and, for the most sensitive actions, real-time alerting to security.

5. Joiner, mover, leaver

5.1 Joiners

• Access is provisioned from a role template tied to the new hire's documented job function. Ad-hoc grants outside the template are recorded with a justification.
• Background checks are completed before privileged access is granted, to the extent permitted by local law.
• Confidentiality, IP assignment and acceptable use obligations are signed before any access is issued.

5.2 Movers

• On role change, access is re-baselined to the new role's template. Permissions from the previous role are revoked rather than accumulated.
• Privilege accumulation is detected by automated reconciliation between role templates and actual entitlements.

5.3 Leavers

• Departure triggers immediate, automated deprovisioning across SSO, every connected SaaS, source-code hosting, cloud accounts, secret stores and physical access.
• Personal device tokens and refresh tokens are revoked.
• A documented exit checklist is completed and signed off by the identity admin.

6. Periodic access reviews

• Quarterly. System owners review every user with access to their system, confirm continued business need and revoke unused or excessive entitlements. Reviews are tracked, evidenced and retained.
• Monthly. Privileged accounts (production access, secret managers, security admin, billing admin) are reviewed and reconciled against the active personnel register.
• Continuous. Automated controls detect dormant credentials (no use within a defined window), unused access grants and entitlements that drift from the role template. Findings are routed to the relevant owner and remediated under a defined SLO.
• Event-driven. Any role change, contract change, departure, suspected compromise or material incident triggers an out-of-cycle review of the affected identities and adjacent entitlements.
• Third parties and contractors. Reviewed on the same cadence as employees, with access expiry dates set at the point of grant.

7. Customer and external access

• Customer administrators manage their own users, roles and SSO configuration; Prodia does not provision into customer tenants except where explicitly requested under a support engagement.
• Support access into a customer tenant is opt-in, time-bound, logged, and visible to the customer in the audit trail.
• Sub-processors are governed by the Data Processing Addendum and the published sub-processor register; access to customer data by sub-processors is contractually constrained and reviewed.

8. Logging, monitoring and evidence

• Authentication events, authorization decisions, privilege grants and privileged-session activity are written to centralised, tamper-evident security logs with defined retention.
• Anomalies (impossible travel, unfamiliar device, brute-force, dormant-account reactivation, abnormal privilege use) trigger alerts to security with documented response runbooks.
• Evidence of access reviews, grants, revocations and exceptions is retained for the durations required by applicable frameworks (GDPR, SOC 2, ISO/IEC 27001, ISO/IEC 42001).

9. Exceptions

Exceptions to this policy are rare, time-bound, individually approved by security leadership and recorded in the exception register together with the compensating controls applied. Exceptions are reviewed on expiry and are not silently renewed.

10. Document availability

The underlying access control standard, role templates, review evidence and control matrices are available under non-disclosure to current customers and qualified prospects on request to trust@prodia.dev.