116 posts tagged with "Changed"

User login events are now shown in the Stax activity feed in the organization dashboard, allowing some users to view user login activity on a more granular level using query filters.

As part of this change, the logins panel has also been removed. Additionally, login token refresh events and login via API token events will no longer be recorded.

User login events are only visible to admin and operations users in Stax-managed organizations.

Stax now shows the last login time for users for the following Stax API endpoints:

• Fetch Stax Users and Federated Users
• Fetch Current User
• Fetch Stax User or Federated User
• Fetch Stax User or Federated User
• Delete Stax User

For more information, please refer to the API documentation for your Stax tenancy.

The last login time can also be viewed from the Stax console by clicking on a user in the Users table.

All users in a Stax-managed organization may see the last login time for their own user details. However, only users with the Admin or Operations role may see the last login time for other users in the organization as a security measure. Similarly, whether another user has MFA configured or not is now visible to only Admins or Operations users.

The Reset User Password endpoint in the Stax API will now include a Task ID as part of the Details of the response.

For more information, please refer to the API documentation for your Stax tenancy.

Version 1.4.0 of the Stax Python SDK has been released, which resolves some dependency issues relating to the use of the SDK.

Changes in this version include:

• Unpin underlying dependencies, allowing users to use the SDK out of the box without needing to explicitly pin other dependencies for compatibility.
• Python version classifiers have also been updated in the Python Package Index. Python 3.9 is now the new minimum version supported by the Stax Python SDK.
• SDK operations are now derived from a new endpoint in the Stax API. The previous endpoint will continue to exist for now, but it may be retired in the future. Stax recommends using the newest version of the Stax Python SDK to minimise disruption.
  • Due to the above change, the teams.ReadApiTokens operation may take the optional access_key keyword argument (previously named AccessKey).

For more details about the Stax Python SDK, see the repository on GitHub.

Version 1.5.5 of stax2aws has been released. See how to upgrade stax2aws.

Changes:

• Updated dependencies and security patches
• Internal tooling improvements

Version 1.5.4 of stax2aws has been released. See how to upgrade stax2aws.

Changes:

• Windows binaries are now signed
• Updated dependencies and security patches

Stax is updating its existing implementation of the AWS S3 Block Public Access functionality.

Currently Stax will enable the AWS account level setting to Block Public Access in each of your Stax-managed AWS Accounts.

Going forward Stax will apply this protection using the recently announced organization-level enforcement with an Organization S3 Policy.

You can read more about the AWS Announcement here.

Stax will now automatically create a new empty Organization S3 Policy named stax-managed-policy within your AWS Organization. This S3 Policy will be automatically attached to the Root of the AWS Organization. When you enable this protection Stax will set the public_access_block_configuration to all.

For more information on eanbling this, refer to the documentation on Configure AWS Accounts.

If you have any questions or concerns in advance of this, please contact your Customer Success Manager or raise a support case.

Stax is adding additional write permissions to the S3 Bucket Policy of the AWS CloudTrail stax-assurance-cloudtrail S3 logging destination. These additional permissions will allow you to leverage the existing Customer managed AWS KMS key and Trail log bucket for additional CloudTrail Trails for the purpose of capturing highly configurable Data events.

Please see AWS CloudTrail for additional details and configuration steps.

On Tuesday 7th October 2025, Stax will be removing legacy resources in your Stax-managed AWS Accounts that exist to meet earlier version of the CIS AWS Foundations Benchmark.

New resources will be deployed that make use of AWS Organization features to centralize these recommendations to the Management and Security AWS Accounts.

These changes are aimed to reduce the time taken to perform Stax Assurance and reduce the number of Stax-managed resources in your AWS Accounts. This will in turn result in a decrease in cost for your AWS Accounts.

A new SNS Topic named stax-cis-benchmark will be created in the Security account. All CIS recommendations will be forwarding their alarm state to this SNS Topic.

If you are currently subscribed to the existing decentralized stax-assurance-cis-benchmark-EventIngestTopic SNS Topics in each AWS account, you must create a new subscription to the new topic.

You can read more about how Stax and the CIS AWS Foundations Benchmark work together.

If you have any questions or concerns in advance of this, please contact your Customer Success Manager or raise a support case.

Stax currently configures your AWS Accounts to automatically disable unused IAM credentials after 90 days to comply with a previous version of the CIS AWS Foundation Benchmark.

To meet newer versions of the CIS AWS Foundation Benchmark and other frameworks Stax will be lowering the current 90 days to 45 days. You can read more about this at IAM Control and the docs.

This change will be automatically deployed to all AWS Accounts on the 17th September 2025.

If you have any questions or concerns in advance of this, please contact your Customer Success Manager or raise a support case.