The challenge behind the engagement.
Authentication, Authorization & Permission Design settles three decisions usually made one application at a time: how people prove identity, how sign-in tokens are issued and accepted, and how permissions are structured. We set the strength of proof required for each group of users and each resource, then plan the phishing-resistant rollout, such as hardware security keys and device-based sign-in, with the strongest methods reserved for administrators. We review your applications and interfaces against current secure sign-in practice: proven grant flows, tokens restricted to one audience, and rotating refresh credentials. We choose a role-based, attribute-based, or relationship-based model per system and provide sample policies. You receive a sign-in standard, a token standard, a role and permission matrix, and authorization test cases. This is design, not an audit opinion.
For security architects and product engineering leads rolling out phishing-resistant sign-in, or building a multi-tenant product that needs document-level sharing. Also for teams cleaning up cloud and directory permissions before an audit or customer review asks how least privilege is enforced.
What we do.
What you can use.
Set assurance levels and methods
We take the application inventory with how each one signs users in, the sign-in system configuration, and permission data and sign-in logs for last-used analysis. Role workshops with product owners follow. From this we set the strength-of-proof target per group and resource and pick the method, session length, and re-authentication rule for each.
Review tokens and policies line by line
We read the sign-in and interface gateway configuration against current secure practice: which grant flows are used, where users are sent back after login, tokens restricted to a single audience, stronger binding for high-value interfaces, and the metadata that lets agent connectors authorize safely. We test the authorization model against sharing, hierarchy, and multi-tenant cases and pick the model per system.
Deliver standards, matrix, and test cases
You receive the sign-in standard, a rollout plan with pilots and exceptions, the token standard, and a role matrix. Drafts cover cloud guardrails that cap what any account can do and on-demand elevation, plus authorization test cases your engineers run automatically. After rollout we confirm the weakest sign-in factors are disabled.
Who it’s for.
When you need it.
- Security architects standardizing authentication across populations with mixed assurance requirements
- Product engineering teams building multi-tenant SaaS that needs fine-grained, relationship-based sharing
- Organizations rolling out phishing-resistant sign-in, with the strongest methods reserved for administrators
- Teams whose permissions accreted per application into roles nobody can review
- A phishing incident or push-bombing attempt exposed weak second factors
- A new product needs document-level sharing that role-based access cannot express
- An audit or customer review asks how least privilege is enforced
- Password rotation and complexity rules are overdue for a policy overhaul
What the scope can include.
- 01
Strength-of-proof target per user population and resource
- 02
Phishing-resistant rollout plan covering hardware keys, device-based sign-in, and certificates
- 03
Password policy set to current guidance: length, no forced composition or rotation, breach screening
- 04
Review of your applications and interfaces against current secure sign-in practice
- 05
Authorization model selection per system: role-based, attribute-based, or relationship-based
- 06
Cloud least-privilege guardrails that cap accounts, plus on-demand elevation
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and the final deliverables included. Find the size closest to yours.
One staff group and a few applications
About 32–60 hoursStaff and admin groups across 5 to 15 applications and interfaces
About 80–140 hoursCustomer and staff sign-in across dozens of applications and interfaces
About 160–260 hours- Number of applications and interfaces to review
- Number of user groups needing different sign-in strength
- Whether customer-facing sign-in is in scope as well as staff
- Complexity of the permission model each system needs
2–3 weeks for a few applications; 6–10 weeks for a large application portfolio
Get a fixed quote for your scopeRanges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Sign-in standard with strength targets, methods per population, and session policy
- Token standard with grant flows, login-return rules, single-audience tokens, and refresh rotation
- Authorization decision record with the model per system, sample policies, and a role matrix
- Guardrail configuration drafts for account caps and on-demand elevation, plus test cases
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
Do we need hardware keys for everyone, or is device-based sign-in enough?
For most staff, a phishing-resistant sign-in built into a managed phone or laptop is enough. Administrators, break-glass accounts, and anyone who can change the environment should hold the strongest methods, which the everyday built-in options do not meet. Those users get dedicated hardware security keys, device-bound sign-in, or certificate-based sign-in. We write the split by population into the sign-in standard and configure it so the right method is required for the right resource.
Our product needs document-level sharing. Is role-based access enough?
Usually not on its own. Roles work when permissions are flat and stable. Sharing a document with one person, inheriting access through folders, or letting a customer's own administrator delegate inside their space are relationships, and forcing them into roles produces a pile nobody can review. We model those cases as relationship-based access, or as attribute rules where the object and context decide, and keep roles for the coarse tiers. The decision record shows the model per system with sample policies and tests.
- NIST SP 800-63-4: Digital Identity Guidelines
- NIST SP 800-207: Zero Trust Architecture
- Zero Trust Maturity Model | CISA
- OWASP Non-Human Identities Top 10
- Securing privileged access Enterprise access model - Privileged access | Microsoft Learn
- What is Microsoft Entra Agent ID? - Microsoft Entra Agent ID | Microsoft Learn
- RFC 9700: Best Current Practice for OAuth 2.0 Security