diff --git a/docs/settings/reporting-settings.asciidoc b/docs/settings/reporting-settings.asciidoc
index 49aa22de9fd35..9dd84ce14a56b 100644
--- a/docs/settings/reporting-settings.asciidoc
+++ b/docs/settings/reporting-settings.asciidoc
@@ -68,17 +68,27 @@ are allowed to generate reports.
 
 [NOTE]
 ============================================================================
-The `xpack.reporting.roles` settings are for a deprecated system of access control in Reporting. Turning off
-this feature allows API keys to generate reports, and allows reporting access through {kib} application
-privileges. We recommend that you explicitly turn off reporting's deprecated access control feature by adding
-`xpack.reporting.roles.enabled: false` to kibana.yml. This will enable you to create custom roles that provide
-application privileges for reporting, as described in <<grant-user-access, granting users access to
+In Kibana 8.x, the `xpack.reporting.roles.enabled` setting controls the model of access control features used for Reporting, which defaults to `true`.
+This enables an older access control model separate from {kib} application privileges, and grants any user with the built-in
+`reporting_user` role the ability to create any type of report in Kibana. But as this model is not based on {kib} application privileges, users that do
+not have permission to create reports will still see {report-features} in Kibana, but will actually receive an error if they attempt to request a report. The default
+model also does not allow API keys or authentication tokens to authorize report generation. 
+
+We recommend that you explicitly opt-out of the default access control model by adding `xpack.reporting.roles.enabled: false` to kibana.yml. This will
+enable you to create custom roles that provide application privileges for reporting, as described in <<grant-user-access, granting users access to
 reporting>>.
+
+In version 9.0, the `xpack.reporting.roles.enabled` setting will be ignored. {kib} will only use the access control model based on application
+privileges, and the built-in `reporting_user` role will have the necessary privileges to generate reports everywhere that Reporting is supported in
+{kib} as of version 9.0. We still recommend that you create custom roles with granular application privileges, in order to grant the least amount of
+privilege that users need.
 ============================================================================
 
 [[xpack-reporting-roles-enabled]] `xpack.reporting.roles.enabled`::
-deprecated:[7.14.0,The default for this setting will be `false` in an upcoming version of {kib}.] Sets access
-control to a set of assigned reporting roles, specified by `xpack.reporting.roles.allow`. Defaults to `true`.
+deprecated:[7.14.0,This setting will be ignored in an upcoming version of {kib}.] Sets access
+control to allow users to generate reports when they are assigned the built-in `reporting_user`
+role. This also grants privileges to users that have a role from a set of assigned reporting
+roles, specified by `xpack.reporting.roles.allow`. Defaults to `true`.
 
 `xpack.reporting.roles.allow`::
 deprecated:[7.14.0] In addition to superusers, specifies the roles that can generate reports using the
diff --git a/docs/setup/configuring-reporting.asciidoc b/docs/setup/configuring-reporting.asciidoc
index 61ef028d1504f..990e814267ae6 100644
--- a/docs/setup/configuring-reporting.asciidoc
+++ b/docs/setup/configuring-reporting.asciidoc
@@ -35,16 +35,20 @@ to enable the {kib} server to have screenshotting capabilities.
 [float]
 [[grant-user-access]]
 === Grant users access to reporting
-When security is enabled, you grant users access to {report-features} with <<kibana-privileges, {kib} application privileges>>, which allow you to create custom roles that control the spaces and applications where users generate reports.
+When security is enabled, the preferred method to grant users access to {report-features} is with <<kibana-privileges, {kib} application privileges>>. This will allow you to create custom roles that control the spaces and applications where users may generate reports.
 
-. Enable application privileges in Reporting. To enable, turn off the default user access control features in `kibana.yml`:
+. We recommend you explicitly opt-out of the default access control model, which will enable application privileges in Reporting. To do this, change a setting that controls the Reporting access control model in `kibana.yml`:
 +
 [source,yaml]
 ------------------------------------
 xpack.reporting.roles.enabled: false
 ------------------------------------
 +
-NOTE: If you use the default settings, you can still create a custom role that grants reporting privileges. The default role is `reporting_user`. This behavior is being deprecated and does not allow application-level access controls for {report-features}, and does not allow API keys or authentication tokens to authorize report generation. Refer to <<reporting-advanced-settings, reporting security settings>> for information and caveats about the deprecated access control features.
+NOTE: In Kibana 8.x versions, the default `xpack.reporting.roles.enabled: true` setting uses an older access control model separate from {kib} application
+privileges. The default model grants users with the built-in `reporting_user` role access to create any type of report in Kibana. Since the default model
+is not based on {kib} application privileges, users that do not have permission to create reports will see {report-features} in Kibana, but will receive an
+error if they attempt to request a report. The default model also does not allow API keys or authentication tokens to authorize report generation. Refer to
+<<reporting-advanced-settings, reporting security settings>> for information and caveats about the `xpack.reporting.roles.enabled` settings.
 
 . Create the reporting role.