Add device conditions example to OAMP

packages/@okta/vuepress-site/docs/guides/okta-account-management-policy/main/index.md

@@ -112,12 +112,13 @@ The policy allows for the following specific expressions:
 | `accessRequest.{operation}`| `accessRequest` references the access context of the request. `operation` references the account management operation: `enroll`, `unenroll`, `recover`, or `unlockAccount`. | String |
 | `accessRequest.authenticator.{id}` | `accessRequest` references the access context of the request. `authenticator.id` references an optional authenticator `id`, for example, the `id` of a custom authenticator. | String |
 | `accessRequest.authenticator.{key}` | `accessRequest` references the access context of the request. `authenticator.key` references the [authenticator key](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicyRule!path=0/actions/appSignOn/verificationMethod/0/constraints&t=request). | String |
+| <ApiLifecycle access="ea" />`device.profile.{property}` | `device` references the device context of the request. `profile` references the device profile. `property` references device properties such as `registered` or `managed`. <br></br> For information about expressions related to device context, see [Expression Language attributes for devices](https://help.okta.com/okta_help.htm?type=oie&id=csh-fp-policy-custom-expression). | String |
 
 ### Condition Object example
 
 ```bash
 "elCondition": {
-    "condition": "accessRequest.operation == \'enroll\' && ( accessRequest.authenticator.key == \'okta_verify\' || accessRequest.authenticator.key == \'webauthn\' || accessRequest.authenticator.key == \'smart_card_idp\' || accessRequest.authenticator.key == \'yubikey_token\' )"
+    "condition": "accessRequest.operation == \'enroll\' && ( accessRequest.authenticator.key == \'okta_verify\' || accessRequest.authenticator.key == \'webauthn\' || accessRequest.authenticator.key == \'smart_card_idp\' || accessRequest.authenticator.key == \'yubikey_token\' ) || device.profile.platform == MACOS"
 },
 ```
 
@@ -286,7 +287,7 @@ curl --location --request PUT '{yourSubdomain}/api/v1/policies/{policyId}/rules/
 --data '{
     "id": "{ruleId}",
     "name": "sdfsd",
-    "priority": 1,
+    "priority": ,
     "status": "ACTIVE",
     "conditions": {
         "people": {
@@ -341,6 +342,81 @@ There are no changes to the user experience when you move password recovery and
 - [User enumeration prevention](https://help.okta.com/okta_help.htm?type=oie&id=ext_Security_General): Isn't supported in recovery scenarios with the Okta account management policy.
 If a user doesn't meet the requirements of your Okta account management policy, they can't update their profile settings. All fields are read-only, including the Reset, Update, and Remove options for their existing security methods. Also, the authenticators that they haven't enrolled are hidden.
 
+## Add a rule for device conditions
+
+<ApiLifecycle access="ea" />
+
+You can add device conditions to your Okta account management policy rules. Device conditions let you enforce rules based on whether a device is registered or managed. You can also associate a [device assurance policy](/docs/guides/device-assurance-policies/main/) with a rule.
+
+For example, you can create a rule where users can reset their password only when they are using a registered device. Registered devices are devices that are enrolled in Okta Verify.
+
+This request is similar to the request to [add a rule for password recovery and account unlock](#add-a-rule-for-password-recovery-and-account-unlock). However, keep in mind the following:
+
+* Use the same value for `policyId`.
+* Set the value of `priority` above the catch-all rule but below the first [phishing-resistant authenticator](#add-a-rule-for-your-first-phishing-resistant-authenticator) (if you added it). Make sure that the first phishing-resistant authenticator rule stays at priority 1.
+* Set the `device.registered` property to `true`.
+* Your user doesn't need to sign in from a network zone.
+
+If you want to add this rule using the Admin Console, see [Add a rule for authenticator enrollment](https://help.okta.com/okta_help.htm?type=oie&id=ext-oamp-enroll-pr-auth).
+
+### Example device condition request
+
+```bash
+curl --location --request POST '{yourSubdomain}/api/v1/policies/{policyId}/rules' \
+--header 'Accept: application/json' \
+--header 'Content-Type: application/json' \
+--header 'Authorization: SSWS {apiToken}' \
+--data '{
+    "name": "Require registered device for password reset",
+    "priority": 1,
+    "status": "ACTIVE",
+    "conditions": {
+        "people": {
+            "users": {
+                "exclude": []
+            }
+        },
+        "network": {
+            "connection": "ANYWHERE"
+        },
+        "device": {
+            "registered": true,
+            "managed": false,
+            "assurance": {
+                "include": []
+      }
+    },
+   "actions": {
+        "passwordChange": {
+            "access": "ALLOW"
+        },
+        "selfServicePasswordReset": {
+            "access": "ALLOW",
+            "requirement": {
+                "primary": {
+                    "methods": [
+                        "email"
+                    ]
+                },
+                "stepUp": {
+                    "required": false
+                },
+                "accessControl": "AUTH_POLICY"
+            }
+        },
+        "selfServiceUnlock": {
+            "access": "ALLOW"
+        }
+    },
+    "system": false,
+    "type": "PASSWORD"
+}'
+```
+
+### User experience
+
+When a user attempts to reset their password or unlock their account, they must use a registered device to authenticate first.
+
 ## Use the legacy option
 
 You might want to use the Okta account management policy for some processes but not for others. For example, you want to use the Okta account management policy for authenticator enrollment. However, for self-service password recovery, you want to keep using your password policy.