Supported AWS Services & Coverage

Understand what AWS information Securitain currently assesses and which product capabilities depend on each source.

Last updated: 2026-09-01

Securitain is intentionally transparent about coverage. A capability should be considered supported only when its customer connection, production collection and product behavior are aligned. Coverage can also depend on AWS account type, enabled setup options, AWS service availability, region, read permissions and scan freshness.

How to read this page

Coverage is described at the capability level. A service can appear in several different contexts. For example, S3 can participate in Resource Policies, Data Security posture, Identity-to-Data and sensitive permissions. Support in one context does not automatically mean every S3 security feature is assessed.

Support definition

Connection permissions
        +
Production collection
        +
Analysis / persistence
        +
Customer-facing API/UI
        +
Expected scan/failure semantics
        ↓
Public Supported Capability

Coverage status vocabulary

• Supported: end-to-end production capability is available.
• Conditional: supported when the AWS environment and connection have the required context — for example, Organizations or Identity Center.
• Optional setup: capability requires an optional connection permission group to be enabled — for example, CloudTrail audit or Resource Exposure audit.
• Limited scope: a real production capability exists, but service, region or semantic coverage is intentionally bounded.
• Release-gated: backend capability exists but connection-permission alignment or end-to-end testing is required before public coverage is claimed.

Core AWS identity sources

AWS Security Token Service (STS)

Coverage: Supported

Used for customer-controlled role assumption, temporary AWS sessions and caller/account identity validation. Securitain does not require customers to create a permanent IAM access key for standard assessment.

AWS Identity and Access Management (IAM)

Coverage: Supported

Current IAM product coverage includes supported context for:

• IAM users, groups, roles
• managed/customer policies and inline policies
• access keys and credential report
• root-account posture and password policy
• service-last-accessed context
• role trust and trust-policy analysis
• permissions boundaries — presence/missing context; deeper policy-content analysis pending boundary-document collection
• effective-permission analysis
• sensitive permissions
• least-privilege analysis
• privilege escalation and relationship graph
• findings, governance, compliance mapping and reports

This does not mean every possible AWS authorization request context is simulated. Use each capability's limitations section.

AWS IAM Access Analyzer

Coverage: Supporting connection capability

The current connection requests Access Analyzer read/validation permissions and tests the capability. Securitain also uses Access Analyzer concepts in security guidance and control context. No dedicated Access Analyzer findings page is currently documented as a shipped product surface.

Workforce and organization governance

AWS IAM Identity Center

Coverage: Conditional

Current supported product context:

• permission sets with managed-policy and inline policy context
• session duration
• assignments per permission set
• target accounts and admin/risk context

Current limitation: no dedicated organization-wide assignment matrix is documented as shipped. Availability depends on Identity Center being used, required AWS read context and successful collection.

AWS Organizations

Coverage: Conditional

Current supported context:

• organization/root context and Organizational Units
• accounts represented in OU hierarchy
• Service Control Policies, policy documents and directly attached targets
• per-level SCP evaluation (union within a level, intersection across levels, explicit deny wins anywhere) — used in Explain Access and Effective Permissions where hierarchy data is available

Important limitation: the Organizations view is not a universal real-time simulator of every inherited effective SCP on every principal. Where the SCP hierarchy is incomplete or unavailable, access explanation returns Indeterminate for the SCP layer rather than assuming the layer is unrestricted. Use Effective Permissions and Explain Access for supported permission consequence context. Availability depends on an account or role with appropriate Organizations visibility.

Compute and workload identity

Amazon EKS / Kubernetes workload identity

Coverage: Supported — scoped (machine identity classification from trust-policy evidence)

Securitain identifies IAM roles used by Kubernetes workloads in Amazon EKS by reading their trust policies — the same IAM trust-policy collection that powers Role Trust analysis. No EKS cluster API call is made and no Kubernetes API is contacted.

Two trust-policy patterns are recognized at high confidence:

• EKS IRSA (IAM Roles for Service Accounts): an IAM role whose trust policy contains an OIDC Federated principal with a system:serviceaccount: subject condition — the standard pattern for pod-level AWS credential access via OIDC.
• EKS Pod Identity: an IAM role whose trust policy contains the EKS Pod Identity service principal — the newer cluster-managed credential delivery mechanism.

Product surface: Machine Identities under Exposure, which lists classified workload identities with their blast-radius score, effective permissions and privilege escalation context.

Activity evidence

AWS CloudTrail

Coverage: Optional setup / supporting evidence

The current connection can optionally request CloudTrail read capability. CloudTrail can support activity context, least-privilege analysis, security evidence and recent-change/activity analysis where productized. CloudTrail evidence depends on connection capability, AWS event availability, time window and product collector.

Resource-policy exposure coverage

The following reflects the production collector, not the broader internal engine or CloudFormation permission intent.

Amazon S3 resource policies

Coverage: Supported / optional Resource Exposure setup

Current production collector supports S3 bucket policies. Product use: Resource Policies, public/cross-account resource exposure. S3 bucket posture in Data Security is a separate capability.

AWS KMS key policies

Coverage: Supported / optional Resource Exposure setup — limited regional scope

Current production resource-policy collector supports KMS key policies for configured collector regions. Data Security KMS posture is a separate capability.

Amazon SQS resource policies

Coverage: Supported / optional Resource Exposure setup — limited regional scope

Current production collector reads SQS policy attributes for configured collector regions.

Amazon SNS resource policies

Coverage: Supported / optional Resource Exposure setup — limited regional scope

Current production collector reads SNS topic policy attributes for configured collector regions.

Lambda / Secrets Manager / ECR / EventBridge resource policies

Lambda resource-policy authorization correlation: Supported / optional Resource Exposure setup

Secrets Manager resource-policy authorization correlation: Supported / optional Resource Exposure setup

Lambda and Secrets Manager resource policies are collected and used for authorization correlation — specifically within Explain Access and Who Can Access This?. This means Securitain can include the resource policy layer when evaluating whether an identity can reach a Lambda function or Secrets Manager secret. The collector reads policy documents only — not function code, secret values or runtime data.

Lambda and Secrets Manager are not currently included in the standalone exposure and risk-classification view (which covers S3, KMS, SQS and SNS). ECR and EventBridge resource policies are not currently supported through the production collector. Do not interpret CloudFormation permission or internal engine concepts as current product coverage for those services.

Resource-policy regional scope

Resource-policy coverage for regional services (KMS, SQS, SNS) is available in a supported set of AWS regions. S3 bucket policy collection is global/list-buckets based and behaves differently. Do not interpret S3 coverage as a statement about all regional services.

Data Security coverage

The Data Security backend has real collectors for S3, KMS, RDS and DynamoDB. The connection permission contract is being aligned before these are marked as fully end-to-end supported in this reference.

Once connection-permission alignment is complete, the target coverage is:

• Amazon S3 Data Security — encryption, public-access context, versioning, access logging, region, findings and supported classification metadata. Not currently covered: MFA Delete, content inspection.
• AWS KMS Data Security — key inventory, supported key metadata, automatic rotation, findings. Key-use history is not claimed.
• Amazon RDS — storage encryption, public accessibility property, automated backup posture, resource/engine context, findings. Important: PubliclyAccessible=true does not by itself prove internet network reachability.
• Amazon DynamoDB — table inventory, encryption-at-rest/key-management context, supported tagging/classification context, findings. DynamoDB is encrypted at rest even when using AWS-owned encryption.

Identity-to-Data coverage

Coverage: Limited / support-dependent

Current product can represent supported sensitive-access relationships with fields such as principal, action, resource, resource service, access type, source context, severity and last-seen context. Identity-to-Data is not a universal resource-level simulator, complete every-service data lineage or content-level sensitive-data discovery.

Service coverage is not action coverage

A service being listed does not mean every AWS API or action is analyzed. For example, KMS being supported does not mean every possible KMS grant, custom key-store behavior, imported key edge case and runtime condition is modeled. Feature-specific limitations are documented on each capability's page.

Regions

AWS partitions

Unless otherwise stated, current coverage applies to supported services in the standard commercial AWS partition. Do not assume support for AWS GovCloud (US), AWS China or other isolated partitions without explicit verification.

Read-only vs service coverage

All required permissions are read-oriented. Securitain's public trust model depends on read-oriented assessment. If a proposed new capability requires customer AWS write permissions, it should undergo separate product and security review. Do not add write actions to make documentation claims true.

Account prerequisites

Coverage can depend on account role or context:

• Organizations: may require management or delegated organization visibility
• Identity Center: requires an applicable Identity Center instance/context
• Resource Policies: requires optional Resource Exposure read setup
• CloudTrail: requires optional CloudTrail read setup
• Data Security: requires the dedicated Data Security read capability once aligned

Missing permission behavior

If a capability cannot be assessed because required read permission is missing:

• surface the missing capability or permission
• represent the scan as partial where appropriate
• do not call the control passed
• preserve previously collected data according to freshness semantics

This connects the coverage reference to Scan Status.

Supported does not mean certified

This coverage page describes product assessment capability. It does not mean:

• AWS certifies Securitain's interpretation
• every security risk in a service is covered
• the customer is compliant
• absence of a finding proves absence of risk

Coverage table

How to use this page during an investigation

Suppose a product view has no data. Do not immediately conclude: no risk.

• Find the relevant capability here — for example, Organizations & SCPs
• Check coverage requirements — does the selected account have appropriate organization visibility?
• Open Scan Status — look for missing permission, partial scan, failed collector or stale data
• Interpret the empty result — only after confirming coverage should an empty result be read as “no supported result was found in this assessed scope”

Coverage changes over time

AWS evolves and Securitain coverage evolves with it. This reference page is updated when production coverage changes. When a capability listed here changes status, both the table and the relevant feature page should be updated together.

Related guides