What is Quiverstone for?
Quiverstone is built to solve a specific problem for a specific kind of team. Start here to understand what the platform does, who it’s for, and how it fits into your existing AWS environment.
Quiverstone is a hosted cockpit for practices that manage a portfolio of unrelated client AWS Organizations. It inventories Client → Org → Account and brokers temporary access via IAM role assumption with External ID — so you don’t stand up Identity Center (or a user) in every client Org just to do day-2 work.
Cloud engineers and consultants who jump across many client AWS estates — including independent practitioners and the MSPs and professional-services firms they work in.
Also a fit for enterprise AWS platform teams with the same multi-Org inventory and access pain.
Cloud architecture is a specialty some of these teams practice. It is not the gate. Quiverstone is not for teams whose whole world is one Organization with Identity Center already wired.
Access and inventory sprawl across clients: bookmark hopping, per-client passwords, one-off assume-role scripts, and “what accounts does this customer even have?” Profile managers and Granted help once identities exist; they don’t help when the client only gives you a cross-account role.
Organizations and Control Tower govern inside one customer’s Org. Granted, Cloud Glance, and Leapp shine once SSO or profiles exist. Quiverstone is for the operator who must assume across many clients’ Orgs with deploy-a-role + External ID, and keep inventory in one place. It complements your clients’ Orgs and Control Tower — it does not replace them.
No — Quiverstone complements them. Your AWS Organizations structure and Control Tower guardrails remain in place and in effect. Quiverstone sits above that layer to give you unified visibility and access across all of them simultaneously. Think of it as the management cockpit that lets you operate your existing AWS architecture, not a replacement for it.
How does access and security work?
Security and compliance are non-negotiable when granting any platform access to your AWS fleet. These answers cover how Quiverstone handles credentials, IAM access, audit logging, MFA, SSO, and our current compliance posture.
Quiverstone operates on a zero permanent credentials model. It uses your existing browser session to perform IAM role assumption into destination accounts on demand — no long-lived access keys are stored on Quiverstone’s servers. Every access event generates a full CloudTrail audit trail in your own AWS environment, giving you an immutable record of who accessed what and when.
Deploy Quiverstone-managed roles through CloudFormation or StackSets, or reuse existing IAM roles with the required trust relationship. Quiverstone supports direct and chained role assumption with External ID and temporary STS credentials.
You choose the access level:
- Read-Only: view account resources and inventory.
- Power User: broad service operations, with IAM and Organizations administration restricted by the role’s policies.
- Administrator: administrative access, subject to your AWS guardrails.
- Custom: permissions defined by your own IAM policies.
Team access uses Group × Account × Role assignments. The permissions of the selected AWS role determine what a session can do.
Docs: https://docs.quiverstone.io/setup/accounts/access · https://docs.quiverstone.io/setup/roles
Not necessarily. Quiverstone is designed to work with your organization’s existing roles already deployed within your customer accounts. If those roles meet the required trust conditions, you can onboard those accounts without deploying anything new. For fresh accounts, Quiverstone automatically scans your environments and inventories all new accounts without requiring manual configuration.
Multi-factor authentication (MFA) is available to all users on any plan and can be enabled at the individual account level.
Admin-enforced MFA, where a subscription owner requires MFA across all team members, is planned but is not yet available.
Quiverstone is an early-stage SaaS platform and formal SOC 2 Type II and ISO 27001 audit processes are planned to begin in Q1 2027. The platform is built on security-first principles — zero permanent credentials, IAM role assumption with External ID, and full CloudTrail audit logging within your own AWS environment. If your organization has a hard certification requirement today, we recommend reaching out to our team to discuss your timeline.
Quiverstone is hosted on AWS us-east-2 and is accessible globally. At this time, the platform does not offer region-specific data residency options. If your organization has a compliance requirement that mandates data processing or storage within a specific geographic region, we recommend evaluating whether this aligns with your needs before adopting the platform.
Quiverstone is an early-stage SaaS platform and does not currently publish a formal SLA. We operate on a best-effort basis and are committed to transparency about service health. You can monitor real-time and historical service status at status.quiverstone.io.
Custom SSO integration (SAML / external IdP) is on the roadmap and will be available at the Enterprise tier in a future release. For teams on the Free, Consultant, or Pro plans, authentication is handled natively through Quiverstone’s own login system. Enterprise prospects with an SSO requirement should contact our sales team to discuss timeline and availability.
What do you deploy in the client account?
Quiverstone is designed to be up and running in a single session with no rearchitecting required. These answers walk through how onboarding works, how your team operates day-to-day, and what the platform looks like in practice.
Quiverstone never stores long-lived access keys. Access is temporary STS role assumption (direct or chained) with External ID. You choose the IAM permission level on the role:
Read-Only
- Inventory, discovery, safe browsing
- View without changes
Power User
- Day-2 ops without IAM/Org blast radius
- Broad services except IAM & Organizations
Administrator
- Break-glass / full ops
- Full admin in the destination account
Custom
- Least privilege for your practice
- Attach your own policies
Deploy Quiverstone-managed roles (CloudFormation / StackSets) or reuse existing roles that already trust Quiverstone (or your intermediate account). Team access is Group × Account × Role — not one global admin key.
Docs: https://docs.quiverstone.io/setup/accounts/access · https://docs.quiverstone.io/setup/roles
Onboarding is designed to be fast. Because Quiverstone works with your existing IAM roles and AWS Organizations structure, there is no rearchitecting of your environment. The platform automatically discovers and imports your AWS Organization member accounts, so your full account inventory populates without manual entry. Most teams move from sign-up to active use within a single session.
Yes. Quiverstone lets you manage standalone accounts in the same unified view as your AWS Organization member accounts. You can categorize every account by Customer, Organization, or Project and tag engagements by type — Resale, Managed Services, Professional Services — so your team always has the right context at a glance.
Yes — and this is a core part of the platform’s value. In addition to Quiverstone’s built-in repository of common AWS Architect tooling, teams on Pro and Enterprise plans can build and share their own custom libraries of resources, tools, and deployment templates. Your organization’s institutional knowledge — runbooks, standard deployment patterns, compliance scripts — lives in a shared, accessible layer rather than scattered across individual machines or private repos.
Quiverstone uses your cached current browser session to assume the appropriate IAM role into a destination account — no copying access keys, no re-authenticating per account. The result is one-click access to any account in your fleet with a full CloudTrail audit trail, following the same secure access pattern AWS recommends for partner environments.
CLI access is available at the Enterprise tier. A full programmatic API is planned for a future release, also at the Enterprise level. If API-driven workflows or infrastructure-as-code integration are requirements for your team, reach out to discuss your use case.